Tes tanpa Sumber Daya QA

Apa bisa nganakake uji coba aplikasi piranti lunak sing cukup mung karo pangembang lan BA lan ora ana sumber daya QA?

Ana rong sekolah pamikiran ing kene:

Salah sawijining kapercayan manawa kabeh kewan omo gegandhengan karo kode lan yen sampeyan duwe persentase jangkoan tes sing gedhe banget kanggo kode sampeyan, mula tegese sampeyan ora duwe kewan omo. Minangka panguji, kita kabeh ngerti manawa iki ora bener!


Kepercayaan liyane yaiku sampeyan nindakake tes unit sing cukup uga nindakake integrasi, sistem lan pangujian panrima pangguna kanggo mesthekake aplikasi cocog. Sanajan iki minangka ide sing apik, ora praktis amarga pangembang kudu menehi kode fitur anyar!

Kaloro kapercayan kasebut ekstrem banget.


Nyoba kode sampeyan dhewe bisa uga efektif, amarga minangka pangembang sampeyan ngerti bagean kode sampeyan sing kompleks lan cenderung minangka kereta, mula sampeyan bakal fokus ing wilayah kasebut. Uga, ngerti ora ana QA maneh, sampeyan kepeksa nulis kode kualitas, kaya sing dikandhakake dening salah sawijining pangembang



Ing tugas pertamane, aku ora duwe QA. Tanggung jawab kanggo nggawe manawa kode dhewe wis cukup kualitas sadurunge diluncurake, lan aspek kasebut nggawe saya wedi yen aku sinau nulis kode kualitas (tegese sampeyan nyoba kode dhewe kanthi tliti, nindakake QA dhewe).

Apa Pengujian Pengembang Cukup?

Aku yakin minangka langkah sing apik kanggo nyengkuyung pangembang piranti lunak supaya nduweni kepemilikan kualitas kode dhewe, nanging nalika sampeyan nyoba kode dhewe, sampeyan bakal bisa kliwat kabeh kelas bug.

Sampeyan bisa dadi efektif banget kanggo nyekel jinis kewan omo sing bisa dipikirake, nanging iki mesthi kewan omo sing paling gampang ditangkap. Tes sing sampeyan tulis dhewe ora bakal nate nggawe kesalahan nalika sampeyan nganggep apa sing kudu ditindakake kode, jinis input apa sing kudu ditangani, lsp. Kanggo nyekel jinis bug konseptual kasebut pancen mbutuhake tes mungsuh saka wong sing ora ngerti ora diwiwiti saka asumsi sing padha.


Makarya minangka panguji otomatis tegese aku kudu fokus ing tes lan coding kanthi bebarengan, lan aku asring berjuang! Nalika nggawe tes ing tes, aku mung pengin priksa manawa kode bakal dieksekusi lan lulus tes, aku ora repot banget babagan tes apa sejatine amarga fokus utama yaiku nggawe kode. Ora suwe aku ngerti yen aku ngotomatisasi tes tanpa guna sing ora regane.

Titik penting liyane sing kudu dielingi yaiku tes unit mung nemokake kesalahan programmer ing kode, pangujian unit ora ndeteksi kegagalan ing aplikasi kasebut, tegese yen sampeyan duwe jangkoan kode 100%, ora ateges aplikasi gratis bug.

Nalika sampeyan kudu nyoba kode sampeyan dhewe liwat tes unit sadurunge dilulusake, sampeyan uga kudu nduwe tampilan kaping pindho saka sudut pandang tumindak. Asring kita cedhak banget karo kode kasebut supaya bisa ngalahake kanthi bener lan tundhuk kasus-kasus sing aneh banget, lan wong-wong QA sing apik cukup trampil nindakake perkara kasebut. Tes ing level sistem dening pangguna liyane kayata penguji asring nuduhake kewan omo sing menarik banget.

Uga, ora kabeh babagan tes fungsional. Kita kudu preduli lan kuwatir babagan pengujian kinerja, pengujian keamanan, tes kegunaan, lsp, sing dibutuhake yen pengin ngeculake piranti lunak sing berkualitas.


Napa Kita Isih Perlu QA?

Penguji kadhang kala katon minangka bottleneck kanggo kabeh pipa pangiriman. Apa ora bakal luwih apik yen kabeh diotomatisasi tanpa intervensi manual lan ora ana panguji sing nggawe bug kanggo mungkasi rilis?

Bagéyan saka masalah nalika panguji katon minangka kemacetan amarga kurang nduweni kualitas ing para pangembang. Yen kabeh wong pancen nganggep tanggung jawab kanggo kualitas produk (ora mung kode), pangembang lan panguji bisa nggayuh tujuan sing padha.

Penguji bisa masangake karo pangembang kanggo nulis tes unit sing luwih apik lan pangembang bisa mbantu para panguji kanthi nulis cek otomatis lan uga ndhidhik panguji babagan arsitektur aplikasi kasebut supaya bisa ngrancang tes sing apik kanggo nemokake wilayah sing paling bisa rusak sajrone tes sistem.

Ing jagad sing becik, panguji ora kudu nemoni cacat, utawa paling ora cacat sepele. Nalika ana 'tim QA' sing tugase golek cacat, bisa ngganggu para pangembang supaya mung ngandelake panguji kanggo nemokake kabeh cacat nalika pangembang fokus ing pangembangan lan kode.


Nalika langkah Yahoo ngilangi departemen QA lan Pengujian nyengkuyung para pangembang supaya nduweni kepemilikan kualitas produk, isih durung cukup kanggo njamin produk sing kuat. Yen wis ujar manawa, sanajan karo tim panguji, sampeyan isih ora bisa njamin piranti lunak bebas bug, nanging sing penting yaiku manawa piranti lunak kasebut dideleng saka macem-macem sudut pandang lan saka sudut pandang sing beda-beda lan ing kono mupangate nyata fungsi QA sing apik (beda karo tim QA) teka.

Penguji bisa njamin para pangembang ngetutake praktik jaminan kualitas paling apik lan ngewangi desain tes teknis lan bisnis kanggo mbantu ngenali bug sing paling kritis sadurunge ngeculake piranti lunak.