Masalah karo Otomatisasi Tes lan QA Modern

Apa sawetara masalah umum babagan uji coba otomatis ing tangkas lan DevOps?

Pengembangan Piranti Lunak Modern lan QA fokus banget ing otomatisasi tes lan ora cukup kanggo tes eksplorasi.

Apa kita ngeculake piranti lunak kanthi kualitas sing luwih apik kanthi tes otomatis? Aku mikir ora!


Aku bubar nemokake kiriman ing jaringan media sosial sing ujar

Sing dakdeleng ing paling akeh tes lan acara QA saiki biasane yaiku DevOps, Integrasi Terus lan Tes Otomatis.


Sanajan kabeh apik banget, aku ndeleng akeh kasus uji coba sing otomatis.



Aku ndeleng sawetara kewan omo sing dilaporake sajrone tes integrasi lan tes fungsional sanajan kabeh otomatis.

Ing UAT, para pangguna nemokake bug lan liyane amarga tim uji gagal ngenali ing fase sadurunge.

Yen ora mulang wong carane nulis kasus tes sing apik, kita bakal otomatis kanthi otomatis…


Lan interpretasi saka… yaiku 'omong kosong'. :-)

Oalah, ayo ndeleng apa tenan kedadeyan ing jagad Modern QA lan Otomatisasi Tes.



Masalah karo QA Modern

Umume 'Uji Otomatisasi' ing pangembangan tangkas ing kahanan sing angel banget. Industri piranti lunak nyedhiyakake akeh dhuwit kanggo ngrekrut 'Ahli Otomasi Tes' umume kanggo nggawe kapercayan manawa piranti lunak sing dibangun iku berkualitas tinggi. Nanging, kewan omo lan / utawa masalah liyane sing ditemokake bisa ditemokake sajrone UAT utawa lingkungan produksi. Dadi, apa sing kedadeyan?

Cathetan:Kanthi Tes Otomasi, umume aku merujuk Bawang Otomatisasi Tes.

Tes otomatis saiki dadi inti kanggo proses pangembangan piranti lunak modern. Tujuane yaiku kanggo nulungi ngirim piranti lunak kanthi kualitas kanthi bola-bali, nanging apa sejatine?


Apa Penguji isih Tes?

Kasunyatane yaiku ing tim sing paling lincah, panguji ora nyoba maneh.

Tes manual wis ilang kautamane, amarga praktik pangembangan lan budaya kayata lincah lan DevOps , sing nggawe pamisahan ing ruang QA - sing bisa kode lan sing ora bisa.

Sampeyan bakal asring ngrungokake kaya, 'Aku insinyur otomatisasi 100%', utawa '80% otomatis 20% manual', utawa malah luwih elek, 'Aku sengit karo tes manual'. Kaget!

Ing DevOps, kita bakal yakin manawa kabeh kudu otomatis. Ora ana papan kanggo intervensi manual, f.eks. tes manual.


Saiki, umume para penguji ing tim sing lincah ngupayakake nuntut panjaluk 'Otomatisasi Tes'. Ana tekanan kanggo ngotomatisasi saben crita ing sprint, lan ora cukup wektu kanggo tes eksplorasi lengkap.

Masalah, utamane ing pangembangan Agile, yaiku QA njupuk crita pangguna lan ngotomatisasi kriteria panrima. Nalika nindakake, fokus utamane mung kanggo gelut karo katrampilan coding winates supaya bisa lulus tes.

Lumrahe, iki nggawe fokus sempit nalika sampeyan mung kasengsem ing otomatis tes lan ndeleng pass ing pipa build. Iki mung mbuktekake apa sing ana ing kritéria panrima - sing bener utawa sing salah - bisa digunakake lan sampeyan cenderung lali babagan gambaran umum.

Penolakan ing Tes Manual

Semono uga akeh 'penguji tradisional' sing pindhah menyang 'uji coba tangkas' kanthi njupuk sawetara pelajaran kode lan dadi luwih teknis.


Aja salah paham; iki kabeh apik. Aku percaya minangka panguji, kita kudu terus ngupayakake sinau teknologi anyar lan teknologi supaya bisa dadi sumber daya. Kita kudu ngerti tumpukan teknologi yen pengin nyoba sistem kanthi kualitas dhuwur.

Nanging, alasan nyata kenapa akeh panguji manual njupuk inisiatif kasebut yaiku amarga ana kapercayan umum yen 'pengujian otomatis' luwih unggul tinimbang tes manual lan, kodhe nyenengake, bener?

Cathetan:Kanthi tes manual, aku ORA nuduhake cara sekolah lawas kanggo ngetutake skrip lan nglakokake langkah-langkah. Aku ngrujuk marang sing diarani 'panguji eksplorasi' - sing nindakake tes nyata lan kepengin mriksa prilaku sistem kanthi nggunakake skenario sing menarik lan dipikirake.

Sayange, kayane ana penurunan pasar sing akeh banget kanggo para penguji eksplorasi. Iki pancen kabukten. Cukup mbukak sawetara pitakon telusuran kanggo 'penguji manual' lan 'panguji otomatis' ing situs tugas IT, lan delengen asil dhewe.



Masalah karo Otomatisasi Tes

Saiki, ayo ndeleng sebabe umume upaya otomasi tes ora ngasilake apa-apa.

Kesalahan umum sing daklakoni bola-bali:

  • Nduwe pengarepan tes otomatis sing salah
  • Otomatis tes ing lapisan sing salah, ing wektu sing salah lan nggunakake alat sing salah
  • Otomatis tes sing ora ana guna
  • Nglirwakake wilayah penting
  • Skenario utama sing ilang

Pengarepan sing Salah

Sawetara wektu maneh aku nulis postingan blog ing kenapa sampeyan pengin ngotomatisasi tes ? Yen sampeyan durung maca, luwih becik diwaca.

Ringkesan artikel kasebut yaiku sampeyan ngotomatisasi tes sing pengin sampeyan lakoni kanthi rutin. Miturut definisi, iki minangka tes regresi sampeyan sing ngonfirmasi sistem kasebut isih bisa digunakake.

Nanging, yen cek otomatis nemokake akeh masalah regresi, aku bakal takon babagan katrampilan pangembang lan proses pangembangan. Tes Otomatis UI ora kudu [dicekel kanthi biaya] utawa [ganti rugi] kanggo coding sing elek.

Lapisan Salah, Piranti sing Salah lan Wektu sing Salah

Mayoritas 'Insinyur Otomatisasi Tes' ing tim sing lincah, ndeleng crita pangguna lan ngotomatisasi kriteria panrima. Umume wektu iki ditindakake kanthi kombinasi Selenium lan Timun.

Aplikasi web modern saiki wis beda-beda mbedakake antarane backend lan frontend. Backend biasane digawe saka sawetara layanan web utawa API REST kanthi titik pungkasan sing gampang diakses.

Logika aplikasi bisa dites ing lapisan API. Nanging, umume insinyur otomasi tes nggunakake fungsi validasi ing lapisan UI sing paling rumit.

Ana alat uji coba ing kana, kayata Karate lan Rest-Assured, sing nyederhanakake tes API. Kita kudu nggunakake alat kasebut sajrone pembangunan. Sedhih, sawetara insinyur otomasi uji coba ora ngerti dhasar HTTP , apa maneh bisa nulis skenario tes API.

Minangka kanggo tes otomatis UI, Cypress minangka alat sing apik. Luwih kaya alat TDD kanggo pangembang ngarep. Pangembang entuk umpan balik sing cepet banget babagan prilaku komponen UI sing anyar.

Karate lan Cypress dadi 'alat tes pangembangan', yaiku alat sing nuntun lan ndhukung pangembangan. Kalorone entheng, gampang diintegrasi lan bisa disedhiyakake kapercayan ing pembangunan .

Banjur kita bisa nggunakake Selenium utawa Cypress kanggo ngrancang sawetara skenario sing nggunakake sistem end-to-end. Skenario kasebut mbentuk paket regresi ringan lan nyediakake kapercayan ing terus bisnis .

Aku asring keprungu kaya, 'kita ngenteni nganti fitur wis berkembang lan stabil, sadurunge ngotomatisasi tes'. Apa wae panguji sadar ngerti manawa kewan omo fitur anyar luwih gedhe tinimbang kewan omo regresi. Ana kemungkinan sing luwih dhuwur kanggo nemokake masalah karo fitur sing lagi berkembang saiki, tinimbang fitur sing stabil.

Yen sampeyan bakal nglampahi tes otomatisasi wektu, coba coba sejajar karo pangembangan nalika bisa menehi nilai luwih akeh.

Tes Otomatis Tanpa Guna

Aja otomatis saben 'tes' mung kanggo kepentingan kasebut. Wenehake proses mikir ing game kasebut. Sinau babagan diagram arsitektur level dhuwur lan tingkat rendah. Takon apa sing bisa salah. Priksa poin integrasi lan goleki poin gagal potensial.

Gawe pendekatan adhedhasar risiko kanthi otomatis kaya sing sampeyan ngarepake. Apa kemungkinan ana sing gagal, lan apa akibat saka kegagalan kasebut? Yen jawabane dhuwur, skenario kasebut kudu otomatis lan dieksekusi ing saben konstruksi.

Ing saben sprint, kita asring nulis tes otomatis babagan crita pangguna babagan sprint kasebut lan lali integrasi karo fitur liyane. Ana tes sing ringkih utawa ora ana integrasi.

Elinga yen 'tes' kanthi otomatis butuh wektu. Elinga uga kanthi otomatis kanthi tes, sampeyan ora nyoba tenan, sampeyan mung mriksa manawa fitur sing ana ing pitakonan iki wis memenuhi kriteria panrima.

Sampeyan ora bisa uji coba otomatis, nanging sampeyan bisa kanthi otomatis mriksa kasunyatan sing dingerteni.

Mula, saben-saben sampeyan nggunakake 'tes' kanthi otomatis, pikirake wektu sing mbuwang-mbuwang wektu kanthi ora nyoba!

Nglirwakake Area Penting

Aku ndeleng luwih akeh kelalaian iki wiwit lair budaya DevOps.

Ing DevOps, pipa pangiriman, uga skrip penyebaran minangka tulang punggung pangembangan piranti lunak lan pangiriman, nanging meh ora bisa dites.

Ing sawetara taun kepungkur, aku gampang ngomong, yen aku wis ngerteni luwih akeh 'masalah lingkungan' tinimbang bug fungsional. Masalah lingkungan kayata masalah karo server CI, skrip penyebaran, lingkungan tes, lan liya-liyane.

Masalah lingkungan duwe pengaruh serius marang upaya pangembangan lan pengujian. Dheweke nggunakake akeh wektu pangembang lan DevOps lan nyuda proses penyebaran kanthi masif, nanging ora ana pertimbangan kanggo nyoba lan mula bisa nyegah masalah kasebut.

Kita mung nampa minangka bagean saka pangiriman piranti lunak modern.

Kita nglampahi upaya kanggo otomatis tumindak prilaku lan ora nggatekake 'prekara' sing paling penting. Malah luwih elek yaiku kudu gumantung ing tes Selenium kanggo nuduhake manawa penyebaran bisa digunakake utawa ora!

Skenario Kunci sing Ilang

Skenario minangka raja! Sawise kabeh, skenario sing mbukak bug.

Asring, masalah serius bocor ing produksi amarga ora ana sing mikir babagan skenario kasebut. Jumlah tes otomatis sing dieksekusi ora dadi masalah. Yen skenario ora dipikirake utawa dites, ukum sod ngandhani yen ana kesalahan ing kana.

Nanging, ing lingkungan pangembangan sing lincah, ora cukup dedikasi kanggo kegiatan 'Lokakarya Skenario' sing penting iki.



Masalah karo Proses kasebut

Ayo goleki carane masalah ing ndhuwur katon ing skenario pangembangan khas:

  • Pamilik produk nulis crita pangguna kanthi ora utawa kritéria panrima minimal.
  • Ora cukup wektu kanggo sesi perbaikan crita kanggo ngrembug macem-macem skenario kanggo crita pangguna.
  • Kriteria panampa diterjemahake minangka tes panrima - Ya, ana bedane antarane kalorone !
  • Penguji mung nganakake kriteria panrima ing crita pangguna sing biasane nggunakake Selenium lan / utawa Timun.
  • Tes otomatis meh mesthi dadi tanggung jawab 'panguji otomatis'.
  • Pangembang ora ngerti apa sing dilebokake ing paket tes utawa malah ora ngerti carane nglakokake tes otomatis.
  • Tes otomatis ditambahake menyang 'paket regresi' sing terus berkembang mula mbutuhake wektu sing suwe lan suwe kanggo mlaku saben wektu.
  • Tes fungsional otomatis UI digabungake menyang pipa build, sing apik nanging…

Pangembang meksa ngganti pangowahan sing gampang lan kudu ngenteni 30 menit supaya tes otomatis dadi ijo sadurunge fitur utawa bug anyar bisa digunakake kanggo produksi. Ngenteni 30 menit mung yen tes kliwat kaping pisanan. Yen gagal amarga ana sawetara masalah tes utawa lingkungan, butuh wektu luwih suwe.

Nalika tes otomatis mlaku lan QA nyelidiki kegagalan acak, pangembang lan / utawa pamilik produk wis verifikasi implementasine anyar lan seneng diluncurake, nanging ora bisa amarga pambangunan ora ijo.

Sawise suwe, bangunan kasebut dadi ijo utawa manajemen dadi frustasi amarga tes gagal lan njupuk keputusan kanggo ngeculake. Banjur, BOOM, sawise sawetara menit produksi, ana lonjakan 500 kesalahan server.

Gagal Infrastruktur

Gagal kayane nuduhake pola sing padha

  • Gagal ing poin integrasi.
  • Gagal komunikasi karo aplikasi pihak katelu.
  • Layanan web ora 'munggah' lan panjaluk menyang titik pungkasan API gagal.
  • Konfigurasi sing salah ing salah sawijining VM utawa simpul, saengga nyebabake masalah intermiten.

Nanging, durung ana proses kanggo mriksa masalah kasebut minangka bagean saka proses pangembangan utawa pangiriman.

Fokus saka insinyur otomatisasi tes yaiku kanthi otomatis tes fungsional. Ora ana fokus ing kinerja, keamanan utawa ketahanan. Lan mesthi ora ana uji coba prasarana!



Ringkesan

Wayahe wis suwe saya fokus saka otomatis tes fungsional sing ora duwe kesempatan kanggo nemokake masalah fungsional menyang masalah lingkungan sing luwih serius lan umum sing ngrembaka.

Uji Otomatisasi, yen digawe salah utawa tanpa proses mikir , mbuang-buang wektu lan ora menehi regane kanggo sapa wae. Tes otomatis sing elek bisa ngasilake biaya perawatan sing akeh lan ngganggu pembangunan. Pungkasane, siji-sijine solusi yaiku tes bin.

Ing pangembangan piranti lunak modern, umume gaweyan 'Insinyur Otomatisasi Tes' digunakake kanggo perang karo kode otomatis lan supaya 'tes' bisa digunakake tinimbang fokus ing pengujian sing tepat lan njelajah sistem.

Sejatine ora cukup wektu kanggo nulis kode otomatis lan nindakake tes eksplorasi. Kita otomatis crita lan crita lan ora lali tes integrasi, ora lali gambaran umum.

Asring kita pungkasan nglakokake tes otomatis, nanging tes eksplorasi nemokake mayoritas kewan omo. Banjur retrospektif, kita nulis tes otomatis kanggo kewan omo sing ditemokake kanthi tes eksplorasi, kanggo nyekel kewan omo regresi.

Kita kudu milih apa sing kudu diotomatisasi lan diadili babagan keputusan adhedhasar risiko. Apa sing salah, apa kemungkinan kesalahan sing salah lan apa sing bakal mengaruhi pangguna utawa bisnis yen wis salah?

Yen sampeyan duwe bisnis 'Uji Otomatisasi', aja nggunakake Selenium kanggo nyoba fungsi API utawa komponen UI. Nanging, gunakake Selenium kanggo ngotomatisasi sawetara skenario sing migunani lan kritis kanggo nyedhiyakake kapercayan ing kesinambungan bisnis sadurunge saben rilis.

Lan pungkasane, saben sampeyan nggunakake otomatis 'tes', pikirake wektu sing mbuwang-mbuwang wektu kanthi ora nyoba!

Wacan Lanjut: