Get best of the week

Apakah autotest memikirkan bug listrik

Baru-baru ini, otomatisasi pengujian telah disebut "peluru perak" dari semua masalah proyek. Banyak orang memulai otomatisasi dengan sangat spontan dan ringan, tanpa menghitung semua pro dan kontra, pro dan kontra, pemeliharaan dan pengembalian. 

Secara umum, otomatisasi uji adalah alat yang sangat mahal dan spesifik. Oleh karena itu, harus didekati dengan tingkat kematangan kode yang tepat dan proyek itu sendiri. Kalau tidak, Anda dapat menghabiskan jutaan jam dan uang, dan efeknya mikroskopis atau tidak sama sekali.

Pada artikel ini saya mencoba:

  • untuk menerangi "luka anak-anak" dari manajemen tes, berusaha untuk mengotomatiskan segala sesuatu yang tidak disematkan,
  • Jelaskan bagaimana otomatisasi pengujian dapat menguntungkan anggaran proyek tanpa analisis rinci tentang ruang lingkup dan persiapan yang tepat,
  • menyusun peta jalan untuk mempersiapkan otomatisasi proyek.

Sumber 

Trennya adalah bahwa sekarang pengujian lubang plugs otomatisasi di semua proyek, sebenarnya memaku kuku dengan mikroskop. Sampai pada titik bahwa menjadi sulit bagi seorang tester tanpa keterampilan otomatisasi untuk mencari pekerjaan, karena di sebagian besar lowongan, keterampilan dalam analisis uji dan desain uji tidak ada, tetapi pengalaman dalam otomatisasi sesuatu diperlukan.

Saya ingin percaya bahwa dari waktu ke waktu kita semua akan memiliki keinginan obsesif untuk mengotomatisasi semuanya sekaligus, tetapi untuk sekarang daftar periksa akan banyak membantu kita untuk menentukan apakah tes otomatis dalam proyek tersebut diperlukan dan apakah proyek siap untuk mereka. 

Sebenarnya, dengan pemikiran ini, saya pergi untuk membuat presentasi tentang "Strike-2019" dan kemudian menulis posting ini berdasarkan itu.

Kami akan berbicara tentang autotest besar, end-to-end yang mengotomatiskan regresi dalam hal UI dan layanan web. Dan juga apa yang terhubung dengan mereka. Kami tidak akan menyentuh pada topik Tes unit yang ditulis atau harus ditulis pengembang. Ini adalah lapisan pengujian mandiri yang terpisah, dan banyak artikel telah ditulis tentang hal itu:

 
Saya tidak akan menyebutkan nama proyek, saya hanya akan mengatakan bahwa ini adalah sistem informasi yang dirancang untuk beberapa puluh juta pengguna. Ini terintegrasi dengan beberapa portal negara, serta dengan puluhan, jika tidak ratusan, portal regional dan komersial. Karenanya meningkatnya persyaratan untuk keandalan, toleransi kesalahan dan keamanan. Nah, secara umum, sehingga semuanya "berputar dan tidak jatuh." 

Kredo kami pada semua proyek pengujian LANIT adalah peningkatan berkelanjutan. Secara umum, segala sesuatu yang memungkinkan kita untuk menguji lebih cepat, lebih baik, lebih tinggi, lebih kuat, menghemat waktu dan tenaga penguji, dan, sebagai akibatnya, anggaran. Kami telah menerapkan proyek ini, mungkin semua praktik terbaik yang memungkinkan kami memenuhi tenggat waktu dan tugas. Akibatnya, dari chip besar yang belum direalisasi, hanya otomatisasi regresi yang tersisa. Topik ini sendiri cukup lama ada di udara, dan untuk waktu yang lama kami menolaknya, bersandar pada semua anggota tubuh kami, karena keuntungannya tidak terlalu jelas. Tetapi pada akhirnya mereka memutuskan untuk mengotomatisasi. Dan kemudian ada lompatan yang berkepanjangan ke air dingin.
 

Penyimpangan kecil. Metode Otomasi


Ada dua cara utama untuk mengotomatiskan pengujian UI. 

Sumber

Otomatisasi oleh penguji tangan


Anda tidak perlu pergi jauh untuk contoh - semuanya ada di Habré. Saya tidak akan menyebut nama perusahaan. Mereka yang tertarik dengan topik ini mungkin melihat webinar satu setengah jam ini, betapa kerennya mereka, betapa kerennya mereka, bagaimana seluruh tim penguji genggam mempelajari Jawa dari mereka, pergi ke otomatisasi, semuanya tertutup, semuanya bagus, semuanya bekerja, masa depan yang cerah telah tiba. Ada pendekatan semacam itu. 

Pendekatan desain


Dan ada pendekatan kedua: tim penguji otomatis direkrut - dengan pengalaman, dengan pengetahuan dan keterampilan dalam OOP, dan otomasi dilakukan langsung oleh kekuatan tim ini, dan tim penguji manual bertindak sebagai pelanggan dan pakar. Ya, mereka dapat mengalir ke tim otomasi setelah pelatihan, seleksi, tetapi mereka tidak pernah menggabungkan dua peran pada saat yang sama.

Di bawah ini saya menggambarkan fitur dari pendekatan ini, tetapi saya tidak secara khusus menandainya sebagai "plus" atau "minus" - semua orang akan menentukan tanda untuk dirinya sendiri.

Fitur otomatisasi "sendiri"


Sumber

1) Ketika kami mengotomatisasi dengan bantuan penguji manual, kami mendapatkan efek cepat "lihat, tes ini memakan waktu sehari sebelumnya, sekarang saya bisa menggantinya dengan robot, butuh 2 hari, tapi saya tidak berpartisipasi di sini". Secara alami, ini meningkatkan kualifikasi dan memperluas cakrawala para spesialis: mereka mulai memahami kode. Tetapi tidak ada hasil yang jelas dan nyata untuk bisnis ini. Berapa jam yang dihabiskan untuk pengembangan, dan berapa banyak yang bisa dihabiskan jika seseorang dengan pengalaman melakukan ini? Berapa jam disimpan? Seberapa sering kasus uji akan diluncurkan? Dimana? Siapa yang harus ditemani? Berapa biayanya? Ini tidak terlalu baik untuk saya, karena, sayangnya, saya belum melihat pelanggan yang bersedia membayar uang tanpa henti - untuk prosesnya. Karena itu, hasil yang jelas dan nyata selalu penting bagi saya.

2) Tidak ada tenggat waktu. Di satu sisi, itu bagus: tidak ada yang mendorong tim, "mari kita mengotomatisasi semuanya, mari kita cepat belajar", ketegangan tidak tumbuh dalam diri seseorang. Dia terus menguji dengan tangannya dan dengan tenang terjun ke dalam otomatisasi. Di sisi lain, tidak ada tenggat waktu, kami tidak bisa bertanya tentang hasilnya, dan kami tidak mengerti kapan itu akan siap.

3) Tidak ada dukungan kode dan kontinuitas. Di satu sisi, pendekatan yang berbeda, survei menimbulkan metode penulisan yang lebih baik, kadang-kadang, menulis ulang dari awal, Anda dapat mempercepat autotest beberapa kali. Tapi itu megatrack. Selain itu, siapa yang akan menemani semua ini jika spesialis meninggalkan proyek, dan ini terjadi jika mereka pergi ke area bisnis lain atau tim lain? Juga tidak terlalu jelas.

Fitur pendekatan proyek


Sumber

1) Dalam hal ini, kita sudah berbicara tentang proyek. Dan proyeknya apa? Ini adalah sumber daya, waktu, uang. Karenanya, anggaran sedang dihitung di sini, dengan mempertimbangkan semua nuansa yang ada dalam proyek ini. Semua risiko dihitung, semua pekerjaan tambahan dihitung. Dan hanya setelah anggaran disetujui, keputusan dibuat untuk diluncurkan.

2) Berdasarkan hal ini, tahap persiapan kemungkinan tidak cepat, karena perhitungan anggaran untuk sesuatu harus dibangun.

3) Secara alami, tuntutan meningkat ditempatkan pada spesialis yang akan berpartisipasi dalam proyek. 

4) Di sini saya juga akan menuliskan solusi infrastruktur yang kompleks, tetapi lebih lanjut tentang itu nanti. 

5) Modernisasi proses pengujian dan rilis yang ada. Karena autotest adalah elemen baru dari tim. Jika sebelumnya tidak disediakan, masing-masing, Anda perlu mengintegrasikannya ke dalam proses. Penguji otomatis tidak boleh menggantung di sisi kanan, kiri, proyek.

6) Pendekatan proyek memberikan keteraturan, konsistensi, meskipun, di sisi lain, implementasinya bisa lebih lambat daripada penerapan pendekatan pertama.

7) Ya, pelaporan. Banyak pelaporan. Karena untuk anggaran apa pun Anda akan diminta. Oleh karena itu, Anda harus memahami bagaimana autotest bekerja (buruk, baik), tren apa, tren apa, apa yang perlu ditingkatkan, apa yang harus ditingkatkan. Ini dikendalikan oleh pelaporan.

Jalan panjang menuju masa depan yang lebih cerah


Penafian: Kami sangat pintar saat itu (sebenarnya tidak).

Sumber

Berikut ini adalah klasifikasi masalah yang kami temui. Saya akan menganalisis masing-masing secara individual. Saya akan melakukan ini dengan sengaja, sehingga Anda memperhitungkan "rake" ini. Karena masalah-masalah ini, yang tidak diselesaikan pada awal proyek, akan secara langsung mempengaruhi, setidaknya, durasinya, maksimum - mereka akan meningkatkan anggarannya atau bahkan mungkin menutup proyek.

Sumber

  • Tim berbeda - pendekatan berbeda.
  • Lemahnya perendaman dalam fungsi.
  • Struktur kasus uji yang tidak optimal.
  • Dokumentasi kerangka kerja.
  • Masalah komunikasi.
  • Pembelian lisensi tepat waktu.

Berbagai pendekatan otomatisasi


Sumber 

Siksaan beberapa kali


Upaya pertama yang kami lakukan adalah sesuai dengan model pertama (lihat metode nomor 1). Sekelompok kecil penguji inisiatif (tetapi bangga) memutuskan untuk mencoba otomatisasi. Pada umumnya, kami ingin melihat apa yang keluar dari semua itu. Sekarang, tentu saja, kami tidak akan melakukan ini, tetapi kemudian tidak ada pengalaman, dan kami memutuskan untuk mencobanya. 

Sumber

Kami memiliki satu pemimpin tim dengan pengalaman otomatisasi, 3 terbakar dengan keinginan untuk mengotomatisasi tester dan banyak keinginan untuk menguasai jalur ini. Benar, Timlid adalah pendatang baru dan tidak bisa mencurahkan banyak waktu untuk proyek, tetapi efek positif dari karyanya adalah bahwa kami menulis kerangka kerja kami sendiri. Kami melihat kerangka kerja yang ada di sana, mereka mahal dan keren atau gratis, dan instruksi "terlampir pada file secukupnya setelah perakitan" dilampirkan pada mereka. Secara umum, karena beberapa alasan, kami tidak dapat menggunakannya. Karena itu, kami memutuskan untuk menulis kerangka kerja kami sendiri. Pilihan itu sendiri dan proses penulisan adalah topik untuk artikel yang terpisah, atau bahkan bukan satu.

Bukan untuk mengatakan bahwa upaya ini gagal, itu hanya hidup lebih lama dan berakhir. Ketika kami menyadari bahwa kami membutuhkan anggaran, kami membutuhkan pasukan tambahan, kami membutuhkan keterampilan, kami membutuhkan organisasi tim lain. Kami mengotomatiskan sekitar 100 kasus, melihat bahwa itu berhasil, dan dibulatkan.

Percobaan nomor dua


Sumber 

Tidak ada yang memberi isyarat seperti sandwich yang digigit.

Setelah beberapa saat, kami kembali ke topik otomatisasi.

Tetapi, mengingat eksperimen pertama, kami beralih ke metode No. 2. Di sini kami sudah memiliki tim yang agak "terampil", mengotomatisasi lebih dari satu proyek. Tapi di sini kita dihadapkan dengan bencana lain. Tim ini mengikuti jejak tim penguji UI. Bagaimana ini bisa terjadi?

"Kami ingin mengotomatisasi ini!"
- Mungkin kita akan memikirkannya.
- Tidak, kami tidak ingin memikirkan apa pun, kami ingin uji otomatis ini.

Dengan upaya raksasa, mereka mengotomatiskannya, dan bahkan berhasil. Tetapi seiring berjalannya waktu, stabilitas peluncuran mulai menurun, dan ketika kami mengumpulkan tim insinyur otomasi kami sendiri dan mulai menyerahkan proyek kepada mereka, ternyata separuh dari tes dilakukan pada kruk, setengah memeriksa apa yang dimaksudkan mesin, dan bukan apa yang diinginkan oleh penguji manual. 

Dan semua karena autotest dijalankan pada kode mentah, yang menjadi sasaran koreksi harian. Itu set kasus awal tidak benar. Kami harus menceburkan diri ke dalam topik yang ingin kami otomatisasi, dari sudut pandang otomasinya (selanjutnya, mentega). Sangat penting untuk mendekati kasus-kasus yang kami berikan untuk otomatisasi, dan pada titik tertentu membuang beberapa dari mereka, memisahkan beberapa dari mereka, dan seterusnya. Tapi kami tidak melakukannya. 

Apa hasilnya. Kami mengotomatisasi bagian lain, sekitar 300 kasing, setelah proyek berakhir, karena tidak ada stabilitas peluncuran dan tidak ada pemahaman tentang bagaimana menemani ini. Dan kami mengerti bagaimana tidak melakukannya ... untuk kedua kalinya.

Percobaan nomor tiga


Sumber 

Untuk usaha ketiga, kami mendekat, seperti seekor burung pemalu ke lubang air. 

Risiko sekitar gergaji (dan gangguan persyaratan). Mereka mendekati secara kritis, pertama-tama, untuk menguji kasus dan penulisnya - penguji UI - sebagai pelanggan proses. Kami menemukan tim berpikir kritis yang sama dari insinyur otomatisasi dan memulai proyek yang dihitung secara normal (seperti yang kami duga), dipersiapkan sepenuhnya (ha ha).

Rake sudah berbaring dan menunggu kami.

Lemahnya perendaman dalam fungsi


Sumber 

Pada tahap pertama (selanjutnya disebut sebagai upaya ketiga), ketika komunikasi masih buruk, penguji otomatis bekerja di belakang layar tertentu: mereka menerima tugas, mereka mengotomatiskan sesuatu di sana. Kami menjalankan autotest. Kami melihat statistik bahwa semuanya buruk dengan kami. Menggali log autotest. Dan di sana, misalnya, jatuh pada kesalahan ejaan nama file yang diunggah. Jelas bahwa penguji, yang menguji fungsi ini dengan tangannya, akan memulai di bawah umur dan melompat untuk memeriksa lebih lanjut. Autotest jatuh dan mengetuk seluruh rantai, yang didasarkan pada basisnya. 

Dan ketika kami mulai membenamkan penguji otomatis dalam fungsional, untuk menjelaskan apa sebenarnya yang kami periksa dalam kasus, maka mereka mulai memahami kesalahan "anak-anak" ini, bagaimana cara menghindarinya, bagaimana menyiasatinya. Ya, ada kesalahan ketik, ada beberapa inkonsistensi, tetapi autotest tidak jatuh, itu hanya mencatatnya.

Struktur test case yang tidak optimal


Sumber 

Ini mungkin sakit kepala terbesar kita. Dia memberi paling banyak masalah, biaya waktu paling banyak, jam terbanyak dan uang yang kita habiskan untuk itu. Akibatnya, pertama-tama kita akan menyelesaikan masalah seperti itu, jika kita mengotomatiskan sesuatu yang lain.

Proyek kami cukup besar, beberapa lusin sistem informasi berputar di dalamnya, mereka dipersatukan oleh kelompok kerja. Dan tampaknya standar untuk penulisan kasus adalah sama untuk semua orang, tetapi dalam satu kelompok karya ini disebut "fungsi", di kelompok lain ini disebut "otoritas", dan autotester membaca "fungsi" dan "otoritas", dan jatuh dalam keadaan pingsan. Ini hanya sebuah contoh. Bahkan, ada ratusan situasi seperti itu. Saya harus membakukan semua ini, menyisir rambut saya.

Apa lagi yang Anda temui selain ambiguitas seperti itu? Kami tidak menemukan kasus uji atom. Ini adalah kasus uji, yang pada beberapa langkah dapat dilakukan secara bervariasi. Misalnya, dalam kondisi, dikatakan "Anda dapat melakukan langkah 2 di bawah otoritas seperti itu dan di bawah otoritas seperti itu", dan pada langkah 3, misalnya, tergantung pada otoritas yang digunakan, "tekan tombol" A "atau tombol" C ". Dari sudut pandang penguji manual, semuanya baik-baik saja. Penguji mengerti bagaimana melewatinya, autotester tidak mengerti bagaimana melewatinya. Dalam versi yang buruk, dia sendiri akan memilih jalan, yang bagus, dia akan datang dengan klarifikasi. Kami menghabiskan cukup banyak waktu untuk mengonversi kasus uji non-atom.   

Dokumentasi Kerangka


Sumber

Anda selalu perlu memikirkan orang-orang yang datang setelah Anda. Bagaimana mereka akan menguraikan kode Anda, menganalisis, dll. Baik jika ada insinyur, programmer yang kompeten. Buruk kalau tidak. Kemudian Anda juga dapat menghadapi kenyataan bahwa Anda perlu membongkar warisan "kemenangan" masa lalu, mendokumentasikan kembali, menarik orang tambahan, menghabiskan waktu ekstra.

Masalah komunikasi


Sumber  

1. Kurangnya peraturan tentang interaksi.

Sebuah tim otomatisasi datang, mereka tidak tahu bagaimana berkomunikasi dengan tim pengujian fungsional manual, dan tidak ada, pada kenyataannya, tahu orang seperti apa mereka. Ya, ada kontak yang berkomunikasi satu sama lain, dan sisanya hanya proyek tetangga. 

2. Adanya peraturan untuk interaksi

Kemudian peraturan itu ditulis, tetapi orang-orang bekerja untuk beberapa waktu tanpa satu sama lain, dan ketika peraturan itu ditulis, mereka menganggap ini sebagai satu-satunya alat untuk interaksi. Segala sesuatu yang melampaui itu diabaikan. 

Artinya, pada awalnya para pria sama sekali tidak tahu bagaimana berkomunikasi satu sama lain, mereka tampaknya berada di ruang obrolan yang sama, tetapi apakah mereka dapat mengajukan pertanyaan atau tidak, mereka tidak tahu. Dan ketika mereka sudah bekerja selama beberapa waktu dalam kondisi seperti itu, mereka mengembangkan komunitas informal dan tertutup mereka sendiri: kami adalah "penjaga tangan", kami adalah automators. Bagaimana cara berkomunikasi? Di sini kita memiliki peraturan - sesuai dengan peraturan tersebut. 

Pembelian tepat waktu lisensi perangkat lunak khusus


Pada titik tertentu, ternyata untuk pengembangan beberapa kasus kita masih memerlukan perangkat lunak berbayar, tetapi tidak ada lisensi untuk itu. Saya harus membelinya dalam api pesanan (sekali lagi, biaya tambahan dalam uang dan downtime). 

Peta jalan


Istonik 

Oleh karena itu, sekarang kita memiliki Roadmap, bagaimana meluncurkan proyek-proyek seperti itu, itu terdiri, pada kenyataannya, tahapan, setiap tahap dibagi menjadi beberapa titik tertentu.

Tahap awal


Sumber 

Kami membutuhkan pemimpin tim


Timlid, seorang arsitek, secara umum, orang yang akan bersama kita sepanjang jalan, orang yang memahami otomatisasi, yang secara teknis cerdas, kompeten. Dianjurkan agar ini menjadi pengembang dengan 5 tahun pengalaman dalam bahasa pemrograman tertentu yang digunakan pada proyek kami. Karena satu atau lain cara, kerangka kerja kami akan bekerja dengan proyek kami. Dengan demikian, yang terbaik adalah jika kerangka kerja dan proyek menggunakan tumpukan teknologi yang sama.

Harus ada grup fokus


Selain itu, ini tidak boleh menjadi kelompok fokus otomatisasi. Mereka haruslah orang-orang yang akan membuat keputusan di masa depan. Lebih baik menjadikan mereka teman sejak awal, sehingga ada pemahaman tentang keputusan apa yang mereka buat, mengapa dan mengapa.

Penilaian status basis kasus uji


Saya sudah berbicara tentang penilaian keadaan dasar kasus uji di atas, masing-masing, ini juga dilakukan pada tahap yang sangat awal.

Kami mencari tahu apa yang tidak dikenakan otomatisasi


Seringkali ada keinginan untuk mengotomatisasi segala sesuatu yang bergerak (dan segala sesuatu yang tidak bergerak, bergerak, dan mengotomatisasi), pada kenyataannya, sekitar 40% dari kasus uji biasanya sangat mahal untuk diterapkan sehingga pada prinsipnya mereka tidak akan pernah membayar. Oleh karena itu, di sini Anda harus sangat jelas tentang apa yang Anda inginkan: untuk mengotomatisasi semuanya dan terbang ke pipa, atau Anda ingin mengotomatisasi pengujian fungsional tertentu yang akan membantu Anda.

Evaluasi proyek percontohan


Kami mengevaluasi proyek percontohan pada tahap awal (berapa biayanya) dan melaksanakannya pada kasus (catatan) yang paling sulit.

Pilot


Sumber 

Normalisasi kasus uji


Kumpulan kasus yang dikumpulkan dapat dinormalisasi. Ambiguitas dan prasyarat yang tidak perlu dihilangkan. 

Persiapan kerangka kerja


Kami menulis kerangka kerja kami, menambahkan yang sudah ada atau menggunakan semacam yang dibeli.

Infrastruktur


Kami sedang mempersiapkan solusi infrastruktur.

Di sini sangat penting untuk tidak kalah: Anda akan memiliki keinginan yang tak tertahankan untuk digunakan pada tahap pertama semacam komputer rumah di bawah meja untuk menjalankan autotest. Ini tidak perlu (tes akan melambat dan jatuh ketika seseorang secara tidak sengaja mematikan komputer atau menumpahkan kopi di atasnya). Hal ini diperlukan untuk menggunakan solusi infrastruktur yang siap pakai, mesin virtual, menonton praktik aplikasi. Karenanya, segera hitung kekuatannya untuk proyek ini dan untuk proyek besar berikutnya. Untuk melakukan ini, kita memerlukan spesialis otomasi.

Subtotal dan penyesuaian


Kami sedang menulis kasus pertama. Kami mengevaluasi kecepatan semua kebahagiaan ini. Kami sedang mengevaluasi kebutuhan tambahan untuk orang-orang, karena kami sudah mengerti berapa banyak kasus ini akan diotomatisasi. Yaitu, kita mengotomatiskan lima buah, sekarang kita perlu memahami berapa banyak orang yang kita butuhkan untuk mengotomatisasi, dengan syarat, 5 ribu lainnya. Beberapa lisensi tambahan, perangkat keras untuk dudukan, baik untuk dudukan yang akan menjalankan autotest, dan untuk dudukan aplikasi itu sendiri. Yah, dan, pada kenyataannya, kebutuhan untuk menyelesaikan kasus uji - seberapa buruk semuanya.

Menyimpulkan pilot


Kami meringkas, menulis laporan, dan membuat keputusan apakah kami akan melakukan otomatisasi atau tidak.

Saya sudah menulis sebelumnya bahwa itu bisa terjadi bahwa kita tidak pergi. Yaitu, jika, misalnya, pengembaliannya adalah 18 tahun, dan jangka waktu proyek Anda adalah 5, Anda harus memikirkan mengapa Anda membutuhkannya.

Tahap peluncuran


 

Item Sumber didaftar secara berurutan, tetapi sebenarnya semuanya harus dilakukan secara paralel.

  • Kami memulai pemilihan tim.
  • Kami menentukan prospek.
  • Mari memprioritaskan studi kasus.
  • Kami menormalkan kasus uji.
  • Kami memecahkan "kesulitan infrastruktur."
  • Kami menulis peraturan dan instruksi, menjalin komunikasi, menghilangkan hambatan.
  • Kami meningkatkan kerangka kerja untuk pekerjaan simultan dari beberapa autotest dan paralelisasi kelompok tes yang berjalan.
  • Kami membuat modul pelaporan dan statistik (satu kali dan kumulatif).
  • Kami mulai menulis autotests.

Panggung utama


Sumber 

Pada tahap utama, semuanya sederhana (haha): autotest ditulis, dukungan tertulis disediakan, hasil peluncuran dievaluasi, keputusan manajemen dibuat, kekuatan diperketat, stream ditambahkan, dan, pada kenyataannya, komunikasi dan komunikasi lagi dengan tim UI. Setiap orang harus berlayar dengan perahu yang sama dan mendayung dalam satu arah.

Tahap pengawalan


Sumber 

Tahap pengawalan sedikit berbeda dari tahap utama. Perbedaan yang signifikan adalah durasinya. Selain itu, persentase autotest baru yang dikembangkan jauh lebih kecil. Menurut perkiraan kami, 6-10% per rilis, jika tidak, ini sangat mirip dengan tahap utama.

Apa hasilnya?


Kami mengotomatiskan sekitar 1.500 kasus end-to-end. Stabilitas peluncuran yang sukses telah mengadakan beberapa rilis di sekitar 92-95%.

Biaya pemulihan menurun hampir 2,5 kali lipat. Berjalan sendiri berlangsung dalam 3-4 jam, ini dilakukan pada malam hari, sehingga pada pagi hari memiliki hasil yang siap pakai.

Rincian implementasi teknis diuraikan dalam serangkaian artikel oleh kolega saya:


Jika kita mulai sekarang, dengan mempertimbangkan semua yang saya tulis, saya pikir kita akan sangat menghemat waktu, saraf, dan anggaran kita.

Terimakasih atas perhatiannya. Ajukan pertanyaan, kita akan membahas. 

Sumber 

Dan juga kami sedang menunggu tim penguji muda kami!
, , .

More articles:


All Articles