Sangat jarang menemukan proyek yang Anda sukai selama wawancara dan yang Anda banggakan saat menaklukkan pasar baru. Itu semua lebih menyenangkan ketika profesionalisme rekan kerja yang terbaik, dan dalam tim Anda, Anda merasa seperti bersama keluarga Anda. Saya beruntung tidak hanya menemukan proyek semacam itu, tetapi juga beberapa waktu lalu mulai memengaruhi proses pengujian di dalamnya. Saya akan memberi tahu Anda apa yang termasuk dalam pemahaman kita tentang proses optimal; bagaimana kami sampai pada rilis bulanan dan bagaimana mereka bekerja untuk kami; dan bagaimana kami beradaptasi dengan kondisi karantina.
Proyek kami adalah sistem pembelajaran jarak jauh (LMS, Learning Management System), yang digunakan oleh lebih dari 7 juta orang di berbagai negara di dunia. Sistem berisi 1000+ halaman web dan sekitar 10.000 kasus uji.
Sekarang proyek tersebut mempekerjakan sekitar 15 tim pengembangan - dari sisi pelanggan di Norwegia dan dari sisi Arcadia di Rusia. Saya bergabung dengan proyek 8 tahun lalu sebagai QA; Selama 2 tahun terakhir saya telah bekerja sebagai pemimpin QA, berpartisipasi dalam pengoptimalan proses pengujian.
Apa yang termasuk dalam konsep proses yang optimal
Tugas utama kami adalah memenuhi kebutuhan pengguna akhir, yang mencakup pembuatan fungsionalitas baru dan dukungan sistem. Perhatian khusus diberikan pada kecepatan sistem dan stabilitas kerja dalam kondisi beban berat.
Proses pengembangan sebaiknya memungkinkan pencapaian tujuan bisnis yang berkelanjutan, seperti menyelesaikan pekerjaan tepat waktu dan dengan tingkat kualitas yang disepakati. Tetapi proses tersebut juga harus nyaman bagi tim pengembangan, sehingga semua orang yang terlibat dalam proses tersebut puas. Dalam tim kami, kami telah menetapkan proses yang optimal bagi kami, dan inilah cara untuk mencapainya.
Proses pengembangan secara umum:
a) Pendekatan pengembangan yang memenuhi kebutuhan tim
Kami bekerja menggunakan Scrum dan sprint yang berlangsung selama 3 minggu. Sebelum sprint, presentasi tujuannya dilakukan dan seperangkat persyaratan untuk sprint ini dibentuk. Selanjutnya adalah perencanaan, di mana kami mengevaluasi semua tugas dan menentukan kumpulan tugas yang akan dimasukkan dalam sprint. Di akhir sprint, tinjauan Sprint berlangsung, di mana kami mendemonstrasikan semua tugas yang telah diselesaikan dan mengumumkan tujuan yang telah dicapai. Pendekatan ini optimal bagi kami: dalam sprint kami berhasil membuat fungsionalitas baru dalam jumlah yang memadai dan pada saat yang sama memperbaiki dan menguji sejumlah bug dari pengguna akhir - 10% dari waktu sprint dialokasikan untuk bug semacam itu.
Berbaris: pemimpin tim, pengembang, penguji. Rasio pengembang dan penguji dalam tim kami adalah 3: 1. Rasio ini memungkinkan untuk mencapai tujuan sprint secara merata - tidak ada periode ketika salah satu peserta proses menganggur: saat pengembang membuat perubahan, penguji membuat atau memperbarui kasus uji yang terkait dengan perubahan ini; Saat pengembangan selesai, penguji memeriksa perubahannya, dan pengembang akan melanjutkan ke tugas berikutnya dalam sprint atau membantu pengujian (ini diperlukan saat menguji perubahan skala besar).
Pemilik Produk menetapkan tujuan dan persyaratan di awal setiap sprint dan menerimanya di akhir. Selain itu, setiap tim memiliki Scrum Master untuk membantu memecahkan masalah yang muncul.
Agar tim mendapat kesempatan untuk melakukan berbagai aktivitas yang tidak berkaitan langsung dengan tugas sprint, serta dengan mempertimbangkan berbagai risiko, waktu yang dihitung untuk menyelesaikan tugas sprint adalah 80% dari total waktu kerja tim. Artinya, 2 jam sehari selama sprint reguler disediakan untuk komunikasi, berbagai rapat dan seminar, serta memperbaiki bug yang ditemukan di sprint.
b) Persyaratan yang jelas dan perencanaan yang baik
Untuk memastikan bahwa perencanaan tidak berlarut-larut dan sprint tidak menjadi kegagalan karena detail yang sebelumnya tidak diketahui dan perubahan tambahan yang melelahkan yang telah ditambahkan selama sprint, kami mencoba untuk memasukkan perubahan hanya pada sprint dengan persyaratan yang cukup jelas dan tepat. Jika area proyek yang menyangkut perubahan tidak diketahui tim, atau selama perencanaan muncul banyak pertanyaan yang tidak dapat dijawab oleh Pemilik Produk, tim dapat melakukan sprint tugas untuk mempelajari area ini atau tugas penelitian, yang menghasilkan persyaratan yang jelas atau bahkan semacam prototipe.
c) Retrospektif
Memperbaiki bug juga penting. Ini berlaku untuk sprint dan rilis. Kebetulan kami tidak punya waktu untuk sesuatu, atau kami harus bekerja lembur untuk memenuhi tenggat waktu - misalnya, jika perlu melakukan pra-uji rilis (dan ini adalah biaya tambahan yang ingin dihindari perusahaan di masa mendatang). Oleh karena itu, kami melakukan retrospektif di mana kami membahas apa yang baik dan buruk dalam sprint atau rilis, dan mengembangkan langkah-langkah untuk menghindari kesalahan tersebut di masa mendatang.
d) Dukungan manajemen
Terkadang pertanyaan atau situasi muncul yang tidak dapat diselesaikan di tingkat tim - Anda perlu mengubah proses atau melibatkan manajemen perusahaan dalam pengambilan keputusan. Sangat penting untuk melihat bahwa mereka ingin membantu Anda dan siap mendukung Anda dalam situasi seperti itu. Di perusahaan kami, semuanya baik-baik saja dengan ini - ini menyangkut baik Arcadia maupun manajemen di pihak pelanggan. Semua masalah dibahas dan selalu ditemukan solusi yang memuaskan semua pihak.
e) Dan menurut saya yang fundamental adalah komunikasi yang baik. Dan apa yang kita miliki di perusahaan, bagi saya, adalah salah satu keuntungan utama dari pekerjaan yang nyaman - kebajikan, keinginan untuk berkompromi.
Ini berlaku untuk semua orang: setiap anggota tim, Pemilik Produk, Scrum Master, manajemen perusahaan, dan banyak peserta lainnya dalam proses tersebut. Setiap orang terbuka untuk pertanyaan dan diskusi, pengembang berkonsultasi dengan penguji tentang persyaratan dan bersama-sama memutuskan cara terbaik (baik dari sudut pandang pengembangan dan dari sudut pandang pengujian) untuk membuat perubahan ini atau itu. Pemilik Produk, pada gilirannya, terus berhubungan dengan tim, segera menyelesaikan semua masalah dan selalu berusaha untuk memenuhi setengah jalan dalam mencapai tujuan sprint. Scrum Master selalu siap membantu: temukan sumber daya tambahan (penguji / pengembang jika mereka diminta untuk sprint atau untuk rilis) atau menyarankan cara terbaik untuk mengatur sprint tepat waktu.
Proses pengujian:
a) QA-standar (pedoman) terkait dengan kasus tes menulis.
Dalam proyek kami, kasus uji adalah dokumentasi terperinci utama tentang fungsionalitas sistem, begitu banyak perhatian diberikan kepada mereka. Untuk setiap perubahan yang dibuat oleh tim, kasus uji baru ditulis atau yang sudah ada diperbarui.
Sebelumnya, ketika sistem belum begitu besar, kasus uji ditulis dengan cukup rinci, dengan berbagai langkah spesifik, tetapi sekarang pendekatan ini menjadi tidak dapat diterima - perlu banyak waktu untuk memperbarui kasus uji tersebut. Oleh karena itu, kami (pemimpin QA) telah mengembangkan standar, yang persyaratan utamanya adalah menulis skrip pengujian dengan hasil yang diharapkan, bukan langkah terperinci dalam kasus pengujian.
b) Standar QA terkait pengujian dalam sprint.
Standar pengujian sprint telah dikembangkan untuk memastikan bahwa setiap tim membuat perubahan kualitas yang baik.
Standar ini didasarkan pada cakupan tes maksimum, yang meliputi:
- Menguji perubahan yang dibuat oleh tim secara langsung (fungsionalitas dan, jika perlu, UI);
- Menguji sistem setelah perubahan ini menggunakan daftar periksa: ini adalah pemeriksaan wajib, yang meliputi pengujian aksesibilitas bagi penyandang disabilitas, pemeriksaan terjemahan, pemeriksaan data yang ada, pengujian menggunakan karakter khusus, pemeriksaan keamanan, pengujian perubahan dalam aplikasi seluler, dan pemeriksaan lainnya. ...
c) Standar QA terkait dengan pengujian rilis.
Proses rilis dan standar yang digunakan di dalamnya dibahas lebih detail di bawah ini.
d) Penggunaan pengujian regresi otomatis.
Pembuatan pengujian otomatis untuk pengujian regresi telah sangat menyederhanakan kehidupan tim - sekarang, jika Anda perlu memeriksa beberapa area setelah perubahan perintah, Anda cukup menjalankan autotests regresi untuk area yang diinginkan dari sistem (jika area ini dicakup oleh tes otomatis). Selain itu, jika beberapa bagian sistem telah rusak karena perubahan tim, autotest regresi akan mendeteksinya.
e) Saling membantu penguji, bantuan pengembang.
Kami tidak memiliki banyak penguji (rata-rata, 1 penguji untuk 3 pengembang), selain itu, dari waktu ke waktu mereka teralihkan dari tugas sprint untuk rilis pengujian, dan mungkin tidak ada cukup waktu untuk semuanya.
Dalam hal ini, selalu ada seseorang dari penguji tim lain dengan beban kerja lebih sedikit saat ini yang dapat membantu. Pemimpin QA atau Scrum Master membantu menemukan penguji seperti itu. Selain itu, pengembang dapat membantu menguji perubahan dalam sprint jika kasus uji telah ditulis untuk mereka.
f) Komunikasi antar penguji.
Untuk komunikasi, obrolan di Microsoft Teams digunakan, di mana setiap orang dapat mengajukan pertanyaan dan mendapatkan jawaban dengan segera, sementara penguji lainnya akan mengetahui informasi terbaru. Kami juga mengadakan pertemuan QA bulanan, di mana penguji saling berbagi tugas saat ini dari tim mereka dan dapat mendiskusikan masalah apa pun - pendekatan untuk menguji dan / atau lokasi kasus uji terkait area yang tidak dikenal oleh penguji; pertanyaan tentang rilis (komposisi tim rilis masa depan, mengubah garis waktu pengujian); pemeriksaan wajib tambahan ditambahkan setelah kehilangan bug kritis dalam rilis, dll.).
Pendekatan di atas memungkinkan Anda memastikan pengujian kualitas yang baik dalam mode operasi yang senyap.
:
Kami dulu memiliki rilis triwulanan . Dengan kerangka waktu seperti itu, banyak sekali perubahan yang dilakukan oleh tim untuk setiap rilisnya. Jumlah perubahan ini tentunya membutuhkan regresi pra-rilis, jadi ada kerangka waktu terpisah untuk regresi dan semua tim terhubung dengannya. Proses ini biasanya membutuhkan waktu sekitar 2 minggu, dan penguji serta pengembang tim berpartisipasi dalam regresi.
Setelah beberapa waktu, pengujian otomatis mulai digunakan untuk regresi dalam proses pengujian rilis. Tidak semua uji regresi dilakukan dengan uji otomatis, beberapa di antaranya diuji secara manual. Secara keseluruhan, ini mengurangi waktu pengujian regresi, tetapi karena ukuran sistem, regresi penuh masih memakan waktu.
Seluruh siklus pengembangan terlihat seperti ini:
Jelas terlihat bahwa pendekatan untuk rilis ini tidak optimal, sangat padat karya, dan tidak memungkinkan kepuasan permintaan pengguna akhir yang cepat dan fleksibel. Pendekatan ke proses rilis memerlukan perubahan, dan diputuskan untuk merilis lebih sering - sebulan sekali.
Saat kami beralih ke rilis bulanan , terlihat jelas bahwa tidak ada waktu untuk melakukan regresi selama fase pengujian rilis - bahkan menggunakan uji regresi otomatis sebagian. Kini total persiapan untuk rilisnya hanya membutuhkan waktu 2 minggu. Oleh karena itu, sekarang regresi dilakukan dalam sprint dan hanya jika diperlukan (jika pengembang melaporkan bahwa diperlukan regresi pada bagian tertentu dari sistem).
Tetapi karena pada tahap pengujian rilis, perlu untuk memeriksa tidak hanya fungsionalitas baru, tetapi juga keadaan umum sistem, kami mulai menggunakan stabilisasi, bukan regresi.
Stabilisasi meliputi:
a) menguji fungsionalitas baru yang disertakan dalam rilis ini oleh setiap tim;
b) Pengujian Area Kritis adalah pengujian fungsionalitas dasar dari area utama sistem (yang jelas membutuhkan waktu lebih sedikit daripada siklus regresi penuh);
c) menguji bug yang ditemukan dalam perubahan tim untuk rilis ini.
Seluruh siklus pengembangan sekarang terlihat seperti ini:
Mari pertimbangkan apa lagi yang diperlukan untuk mempersiapkan rilis.
Saat stabilisasi selesai dan paket rilis memiliki kualitas yang baik, sebelum meluncurkannya ke produksi, konfigurasi tersebut diuji di lingkungan pra-produksi. Karenanya, Operasi berlatih memperbarui lingkungan, dan penguji memeriksa konfigurasi dengan paket rilis saat ini sebelum rilis sebenarnya.
Anda mungkin berpikir bahwa 2 minggu persiapan rilis terlalu banyak, dan hanya ada sedikit waktu tersisa untuk pengujian di sprint. Tetapi biasanya dibutuhkan 4-6 hari bagi penguji untuk mempersiapkan rilis. Itu tergantung pada:
- kompleksitas dan cakupan fungsionalitas yang akan dirilis timnya,
- partisipasi penguji dalam tim rilis rilis saat ini.
Semua penguji proyek (termasuk tim rilis) berpartisipasi dalam pengujian stabilisasi; menguji konfigurasi dan rilis itu sendiri hanya dilakukan oleh tim rilis.
Jadwal pengujian rilis umum terlihat seperti ini:
Karena area kritis dan konfigurasi berisi pengujian konstan, kami telah mengotomatiskan sebagian kasus pengujian ini. Ini telah mengurangi waktu pengujian secara signifikan dalam persiapan rilis, jadi di masa mendatang kami berencana untuk memperluas penggunaan pengujian otomatis.
Dalam hal pengorganisasian pengujian, koordinator QA (seseorang dari pemimpin QA) dipilih untuk setiap rilis. Waktu tunggu untuk rilis biasanya direncanakan untuk koordinator QA lebih dari untuk penguji biasa, karena koordinator QA memiliki lebih banyak tanggung jawab. Ini termasuk:
- mendefinisikan tim rilis dan memeriksa ketersediaan semua anggotanya pada saat rilis;
- persiapan rencana uji untuk rilis;
- meluncurkan tes otomatis pada tahap pengujian stabilisasi dan konfigurasi;
- koordinasi pekerjaan penguji selama pengujian rilis;
- membantu penguji dalam memecahkan semua jenis masalah yang terkait dengan rilis;
- kontrol atas pelaksanaan pengujian dan, jika perlu, redistribusi beban untuk membantu pengujian tim yang kelebihan beban (ini dapat berupa penguji tim lain yang telah menyelesaikan pengujian rilis, atau pengembang tim, atau koordinator QA sendiri).
Dan tentu saja, tidak ada rilis yang lengkap tanpa masalah. Kami menyelesaikannya dan mengembangkan rencana tentang cara menghindarinya di masa depan. Berikut ini beberapa yang kami temukan baru-baru ini:
- : , - , , - .
: . - : pre-production . — .
: . - : , .
:
a) - ( , ),
b) ,
c) ,
d) , . , , .
Solusi: dalam kasus seperti itu, kami mencoba memiliki waktu untuk menguji semua yang diperlukan untuk rilis, meskipun memerlukan partisipasi dalam rilis selama 2 minggu atau kerja lembur, karena rilis adalah tugas dengan prioritas lebih tinggi daripada tugas sprint.
Tetapi tidak peduli masalah apa yang muncul, kami selalu dapat menyelesaikannya dengan kekuatan tim pelepasliaran atau dengan melibatkan orang-orang yang kompeten di area tertentu - yang utama adalah bahwa ini selalu merupakan kerja tim yang terkoordinasi dengan baik yang mengarah ke hasil yang baik.
Bekerja di karantina: bagaimana memastikan pekerjaan penguji
Dalam proyek kami, bekerja dari kantor merupakan prasyarat. Ini dilakukan agar setiap peserta dalam proses dapat ditemukan selama jam kerja - jika tiba-tiba dia tidak menjawab dalam obrolan, maka orang yang bekerja dengannya dapat memberi tahu dia bahwa dia dibutuhkan oleh beberapa rekannya. Ini relevan, karena beberapa tim berada di Norwegia, dan beberapa di St. Petersburg.
Selama pandemi, ketika Norwegia dan Rusia mengirim sebagian besar penduduk ke isolasi diri, kami harus beralih ke pekerjaan jarak jauh.
Kami terus bekerja seperti biasa: tim masih menyelesaikan sprint dengan produktivitas sprint yang baik, dan rilis dirilis tepat waktu.
Komunikasi masih pada tingkat yang baik - aplikasi Teams memenuhi semua kebutuhan: ada percakapan aktif dalam obrolan, rapat diadakan tanpa masalah; jika ada pertanyaan yang perlu didiskusikan segera, mereka akan memanggil setiap peserta proyek.
Dari sudut pandang organisasi pengujian, tidak ada masalah: selama jam kerja, semua penguji menjawab dalam obrolan dan segera berpartisipasi dalam pengujian rilis. Jika kami perlu menemukan seseorang, tetapi dia tidak menjawab dalam obrolan, kami telah menyiapkan daftar nomor ponsel, tetapi kami tidak pernah menggunakannya.
Satu-satunya masalah yang kami hadapi saat duduk di rumah di tempat kerja jarak jauh - karena kekhasan VPN, mustahil untuk menguji sistem dalam lingkungan tim dari ponsel / tablet. Namun masalah ini dapat dielakkan - berkat manajer proyek dan layanan TI, yang menemukan solusinya. Kami mulai menggunakan proxy saat menghubungkan melalui jaringan rumah, dan sekarang kami dapat mengujinya di perangkat seluler dari rumah.
Sekarang kami sebagian kembali bekerja di kantor, tetapi sebagian perusahaan tetap bekerja dari rumah. Dan bahkan berada di berbagai bagian kota, kami masih tetap menjadi satu perusahaan erat yang terus bekerja di masa-masa sulit seperti itu, dengan kondisi tidak bekerja, ketika anak-anak dan hewan peliharaan membutuhkan perhatian, Internet melambat dan menghilang secara berkala, lampu mati, dan ada begitu banyak gangguan faktor yang tidak Anda mengerti sama sekali, bagaimana Anda bisa bekerja lagi ?!
Tapi bersama-sama kita akan selamat dari semua ini, dan akhirnya, setelah kembali ke kehidupan kantor yang lengkap, kita akan tersenyum satu sama lain lebih lebar dari biasanya.
Kesimpulan
Meringkas hal di atas, saya ingin mencatat beberapa poin:
- , , . — .
- , , .
- , , , — . , .