Penafian: nama saya Eric Burygin, saya telah bekerja sebagai penguji untuk waktu yang lama, saya mengajar siswa di kursus "Test Engineer" , jadi tampaknya penguji hanya ingin mentransfer sebagian pekerjaan ke pengembang. Faktanya, pendekatan yang dijelaskan memiliki pro dan kontra, jadi artikel tersebut, antara lain, dapat diperdebatkan. Saya akan senang melihat pendapat dari pengembang dan penguji di komentar.
Jika pengembangan menulis pengujian, Anda dapat menyelesaikan beberapa masalah sekaligus, misalnya:
- Percepat siklus rilis.
- Bongkar pengujian.
Di sebagian besar perintah, prosesnya terlihat seperti ini:
- Pengembang membuat fitur baru dan melengkapi yang sudah ada.
- Penguji menguji semua ini dan menulis berbagai kasus uji.
- Automator, membenarkan judul posisi, mengotomatiskan semuanya sesuai dengan kasus uji tertulis dari klausul 2.
Segalanya tampak sederhana.
Namun ada kelemahan dalam paradigma ini.
Katakanlah seorang pengembang telah menyelesaikan fiturnya dan telah lulus dengan aman untuk pengujian. Tapi fiturnya ternyata bukan medium rare, tapi terus terang mentah. Ini akan mengarah pada penemuan kembali masalah dan perbaikan tambahan, dan bisa ada dari satu ke N iterasi, tergantung pada ukuran fitur ini, kompleksitasnya, dampak pada proses terkait, dan ketelitian pengembang itu sendiri. Dan juga tentang bagaimana proses Anda pada prinsipnya diatur dalam pengembangan, seberapa hati-hati tampilan permintaan tarik, apakah aplikasi diluncurkan sebelum dikirim untuk pengujian.
Secara umum, ada cukup banyak variabel.
Setelah tugas diuji dan siap untuk dirilis, pengujian perlu ditulis untuk seluruh fungsionalitas kasus uji. Kemudian kemunduran / asap dan akhirnya lepaskan.
Setelah menerima kasus uji tertulis, automator mencakup fungsionalitas dengan pengujian. Ada kemungkinan yang cukup tinggi bahwa tugas akan berakhir dalam antrian yang ada, sehingga pengujian akan ditulis dengan penundaan.
- Hanya butuh lebih banyak pengembang
Sayangnya, bukan obat mujarab. Justru sebaliknya. Semakin banyak pengembang yang Anda miliki dalam skema ini, semakin kuat beban pengujian. Akibatnya, siklus rilis atau tim penguji itu sendiri akan meningkat.
Dan ini, menurut prinsip domino, akan meningkatkan beban pada automators, yang harus memproses semakin banyak kasus uji yang jatuh pada mereka dari pengujian. Akan ada situasi cermin: baik waktu cakupan tes akan bertambah, atau staf otomasi akan bertambah.
Biasanya ada dua penguji dan satu insinyur otomasi untuk setiap delapan pengembang. Pada saat yang sama, otomatisasi tidak secara langsung terlibat dalam siklus rilis - melainkan di dekatnya. Dan muncul pertanyaan: bagaimana membuat proses yang dijelaskan lebih efektif, dan bahkan tidak kehilangan kualitas?
Mari kita coba pindahkan tahap otomatisasi dari tempat ketiga ke pertama, ke tahap pengembangan.
Apa yang terjadi
Anda akan segera mendapatkan serangkaian keuntungan yang bagus, lihat:
- pengembang menulis tes secara bersamaan dengan menulis fitur itu sendiri, yang secara signifikan meningkatkan kualitasnya;
- beban pada pengujian berkurang: penguji sekarang perlu melihat hasil pengujian dan menilai apakah tugas tersebut cukup tercakup dalam pengujian;
- regresi manual dalam skema tidak lagi diperlukan.
Bagaimana dengan penguji?
Penguji, bahkan dalam paradigma yang diperbarui, tetap ahli dalam pengujian - dialah yang meninjau kualitas dan kelengkapan cakupan tes otomatis dari fitur tertentu, serta menganalisis masalah yang kompleks dan tidak biasa. Tetapi sekarang, berkat beban yang berkurang, penguji membebaskan sebagian waktunya, dia dapat menangani proses.
Pada saat yang sama, Anda perlu memahami bahwa pengujian manual masih tidak akan berhasil - Anda akan selalu memiliki sesuatu yang karena alasan tertentu tidak mungkin untuk diotomatisasi atau tidak masuk akal.
Jadi, ke paradigma baru. Keren? Ya, setidaknya terapkan sekarang. Jika Anda bisa melakukan dua hal.
- Jual ide ini untuk pengembangan. Karena tidak setiap pengembang akan langsung ingin menulis tes, karena itu bisa membosankan, atau dia hanya tidak ingin: apakah Anda, sebenarnya, memiliki penguji di sana untuk apa?
- Jual ide ini kepada manajer. Sebab, dengan kelebihan lainnya, Anda menambah waktu pengembangan untuk setiap fitur.
Apa kerugian di sini bisa menunggu Anda.
- Sebagian besar pengembang tidak tahu cara menguji, karena mereka adalah pengembang, bukan penguji. Dan tidak apa-apa. Di sini Anda dapat mengajari mereka cara menguji, yang bukan merupakan tugas paling mudah, atau hanya menulis kasus uji untuk mereka. Yang secara de facto merusak proses itu sendiri.
- Pada awalnya, otomatisasi akan membutuhkan lebih banyak waktu, karena tidak akan ada basis kode uji, infrastruktur, dan pendekatan biasa - tugasnya baru.
- Laporan yang jelas akan dibutuhkan untuk pengujian. Namun perlu diingat: bahkan laporan yang paling mudah dipahami pun tidak selalu dapat langsung dibaca dengan benar.
- Anda tidak dapat dengan mudah dan cepat menutupi tidak semua masalah dengan tes. Dalam beberapa kasus, Anda harus menghabiskan lebih banyak waktu untuk pengujian daripada implementasi fitur yang sebenarnya.
- Akan sulit untuk menyampaikan tugas berskala besar pada saat yang sama dengan tes, itu membutuhkan banyak waktu.
- Untuk tugas-tugas berskala besar dan kompleks yang sama, Anda masih harus menyisihkan waktu untuk mempelajarinya, karena tidak ada cara lain untuk memeriksa kebenaran tes yang ditulis oleh pengembang.
Apa yang harus dilakukan?
Pada dasarnya setiap masalah memiliki solusi.
- Pengembang tidak tahu cara menguji. →
Anda dapat berkonsultasi dengan mereka pada tahap awal untuk membantu memahami. - , . →
. . - . →
, , . - . →
: . - , . →
, — . . - . →
. .
Pendekatan dengan segala pro dan kontranya memiliki hak untuk hidup. Dan jika Anda juga mengatur proses dengan benar, maka ini akan membantu Anda mempercepat siklus rilis dan tidak meningkatkan status (: