Praktik pengembangan terus berubah, dan sebagai penguji kita harus merangkul perubahan. Salah satu perubahan yang mungkin kami alami adalah perpindahan dari rilis bulanan atau triwulanan ke pengiriman berkelanjutan atau penerapan berkelanjutan. Selain itu, perpindahan ke pengiriman atau penerapan berkelanjutan ini memberikan kesempatan kepada penguji untuk mempelajari keterampilan baru.

Sebuah proyek yang membuat rilis bulanan atau triwulanan memiliki ritme yang familiar, dan tim membangun menjelang tanggal rilis. Penguji harus menguji semua kartu dan melakukan pengujian regresi manual. Setiap tes skrip manual harus dijalankan dan mungkin laporan harus ditulis pada hasil tes ini. Setelah rilis dirilis, mungkin ada bug dalam rilis yang perlu diperbaiki. Penguji juga harus mulai menjalankan uji regresi manual yang sama pada rilis berikutnya dan melaporkannya lagi. Menguji rilis bulanan atau triwulanan adalah proses berulang. Proses ini telah dibandingkan dengan mitos Yunani Sisyphus, yang harus menggelindingkan sebuah batu ke atas bukit, kemudian ketika batu itu menggelinding ke dasar bukit, dia harus menggelindingkannya lagi ke atas bukit. bukit. .

Pengiriman Berkelanjutan dapat didefinisikan sebagai “saat semua pengembang bekerja dalam batch kecil di lemari besi, …. dan saat lemari besi disimpan dalam keadaan dapat dirilis, dan saat kami dapat melepaskannya dengan menekan tombol”. Sebuah tim tempat saya bekerja beralih dari membuat rilis bulanan menjadi pengiriman berkelanjutan. Tim mempertahankan cabang utama dalam keadaan yang dapat digunakan jika diperlukan, dan tim membuat rilis mingguan. Penerapan berkelanjutan dapat didefinisikan sebagai saat, selain praktik yang mendukung pengiriman berkelanjutan, “kami secara teratur menerapkan build yang bagus untuk produksi melalui swalayan (diterapkan oleh Dev atau Ops). Tim penerapan berkelanjutan menerapkan produksi setiap kali kode digabungkan ke dalam cabang master.

Tim yang mempraktikkan pengiriman berkelanjutan atau penerapan berkelanjutan menggunakan ukuran batch kecil. Ini berarti bahwa “kumpulan” kode yang diterapkan berukuran kecil. “Batas bawah teoretis untuk ukuran lot adalah aliran sepotong demi sepotong, di mana setiap unit dikerjakan satu per satu”; inilah yang terjadi dalam penerapan berkelanjutan di mana setiap penggabungan ke cabang utama diterapkan ke produksi.

Tim yang mempraktikkan pengiriman berkelanjutan dan penerapan berkelanjutan mencoba membangun alur kerja dengan kecepatan yang berkelanjutan dan oleh karena itu perlu “mengaktifkan dan menyuntikkan pembelajaran ke dalam pekerjaan sehari-hari”. Di sisi lain, tim yang merilis build bulanan ke rilis dan karenanya tidak dapat membangun alur kerja konstan tersebut dengan kecepatan yang berkelanjutan.

Saat tim berpindah dari rilis bulanan ke pengiriman berkelanjutan atau penerapan berkelanjutan, perubahan yang terjadi adalah tidak adanya kandidat rilis. Pengujian tidak dilakukan pada kandidat rilis; alih-alih, ini dilakukan pada cabang fitur yang telah ditarik dari cabang master, dan saat digabungkan ke dalam cabang master, mereka harus siap untuk ditayangkan. Cabang master disimpan dalam keadaan di mana ia dapat diproduksi. Untuk penguji, ini berarti pengujian pada cabang fitur memiliki model yang berbeda dengan pengujian pada kandidat rilis.

Saat menguji di cabang fitur, Anda perlu memastikan bahwa fitur atau perbaikan baru di cabang fitur melakukan apa yang seharusnya dilakukan dan tidak menyebabkan regresi apa pun. Saat menguji rilis bulanan, Anda mungkin memiliki waktu untuk menjalankan pengujian regresi manual, tetapi jika cabang master perlu disimpan dalam keadaan yang dapat digunakan untuk produksi, itu tidak mungkin. Pengujian regresi harus diotomatisasi jika Anda menggunakan pengiriman berkelanjutan atau penerapan berkelanjutan.

Pengujian regresi pada rilis bulanan seringkali mencakup menjalankan sejumlah besar pengujian manual; Namun, jika tim Anda menggunakan pengiriman berkelanjutan atau penerapan berkelanjutan, pengujian regresi biasanya diotomatisasi melalui integrasi berkelanjutan. Integrasi berkelanjutan (CI) “berarti bahwa setiap kali seseorang membuat perubahan” pada kode, perubahan tersebut diintegrasikan ke dalam basis kode. Ini melibatkan menjalankan tes otomatis sebelum dan sesudah menggabungkan kode ke dalam cabang master. Ini memberi kesempatan kepada penguji untuk belajar memahami IC. Penguji harus memahami CI, termasuk pengujian yang dijalankan sebagai bagian dari CI. Akan selalu ada celah dalam pengujian yang dijalankan pada CI. Jika penguji mengetahui celah CI, mereka dapat mengetahui cara mengotomatiskan pengujian untuk mengisinya dan menjalankan pengujian manual untuk mengisi celah saat dibutuhkan. Membuat peta pikiran dari pengujian yang otomatis dapat membantu mengidentifikasi celah dalam pengujian otomatis.

Penguji juga dapat terlibat dalam mengotomatiskan pengujian regresi sendiri, dan dengan cara ini penguji dapat membantu mencegah bug daripada menemukannya. Ada sumber daya gratis yang bagus seperti Test Automation University, LambdaTest Certifications, dan Exercism yang dapat membantu penguji mempelajari keterampilan yang diperlukan untuk mengotomatiskan pengujian. Ada juga banyak sumber daya untuk mempelajari cara menggunakan javascript agar pengujian lebih mudah.

Fakta bahwa pengujian regresi diotomatisasi menciptakan waktu bagi penguji untuk melakukan pengujian eksplorasi. Pengujian eksplorasi adalah cara ampuh untuk mengungkap masalah, sehingga akan membantu proyek yang sedang dikerjakan oleh penguji. Memiliki lebih banyak waktu untuk melakukan pengujian eksplorasi juga akan membantu penguji mengembangkan keterampilan pengujian eksplorasi mereka.

Proyek yang menggunakan continuous delivery dan continuous deployment juga cenderung memiliki arsitektur microservices. Layanan mikro adalah layanan yang memiliki pengujian dan penyebaran independen, dan setiap layanan sederhana. Penguji memiliki kesempatan untuk mempelajari lebih lanjut tentang layanan mikro, dan cara untuk melakukannya termasuk berbicara dengan pengembang, mempelajari diagram arsitektur yang ada, membaca file readme untuk setiap layanan di GitHub, dan menghadiri rapat pengembang.

Penguji dapat membangun hubungan dengan pengembang dengan membantu mereka menguji kodenya. Selain itu, penguji dapat membagikan pengetahuan mereka tentang teknik pengujian, seperti analisis nilai batas, dengan pengembang, karena hal ini akan membantu mereka menguji dan menghasilkan perangkat lunak yang lebih baik.

Proses rilis untuk build bulanan dapat menimbulkan rasa sakit bagi penguji. Terkadang kita diminta untuk mengambil tanggung jawab untuk membuat keputusan keluar meskipun penguji sering kali adalah anggota tim junior; di lain waktu, penguji harus berpartisipasi dalam rapat komite pemangku kepentingan besar yang memutuskan apakah perangkat lunak dapat dirilis. Proses rilis untuk penerapan berkelanjutan dan pengiriman berkelanjutan harus diotomatisasi; ini berarti melakukan rilis tidak memberi tekanan pada penguji. Kontribusi penguji untuk rilis dalam pengiriman berkelanjutan dan penerapan berkelanjutan adalah pengujian mereka; itu berarti kita dapat fokus pada pengujian kita dan mempelajari keterampilan pengujian baru.

Tim pengembangan tidak otonom; mereka adalah sistem terbuka yang pekerjaannya memengaruhi tim lain dan dipengaruhi oleh tim lain. Ini adalah pemikiran sistem, dan pemikiran sistem telah berkontribusi pada pengiriman berkelanjutan dan penerapan berkelanjutan. Penguji dapat belajar menggunakan pemikiran sistem untuk meningkatkan pengujian mereka dan mendukung tim mereka. Ini dapat membantu penguji berpikir di luar peran mereka untuk memahami sistem lain mana yang dipengaruhi oleh kerja tim mereka dan sistem mana yang memengaruhi kerja tim mereka.

Salah satu pelajaran dari pemikiran sistem adalah bahwa setiap orang berbagi tanggung jawab, jadi tidak ada yang harus disalahkan ketika terjadi kesalahan. Visi ini juga harus menjadi inti dari setiap tim pengembangan yang ramping dan gesit yang mengimplementasikan continuous delivery atau continuous deployment. Ini adalah sesuatu yang harus dipelajari dan diingat oleh penguji. Ketika ada kegagalan, kita harus belajar darinya dan tidak menyalahkan siapapun.

Tim yang membuat rilis bulanan mungkin menemukan bahwa setelah setiap rilis ada kesibukan memperbaiki bug regresi yang diterapkan dalam rilis. Ini tidak terjadi dengan tim yang mempraktikkan pengiriman berkelanjutan atau penerapan berkelanjutan. Rilis akan diluncurkan beberapa kali sehari menggunakan penerapan berkelanjutan, dan perangkat lunak akan diluncurkan secara teratur dengan pengiriman berkelanjutan. Rilis reguler ini memberi tim pengembangan kemampuan untuk pulih dari bug dan crash dengan cepat, karena perbaikan dapat diluncurkan dengan cepat. Setelah tambalan diterapkan, penguji dapat menawarkan untuk berinisiatif melakukan analisis akar penyebab guna menemukan akar penyebab bug atau kerusakan. Penguji dapat belajar menggunakan Lima Mengapa dan diagram tulang ikan untuk melakukan analisis akar masalah.

Penguji juga dapat mendukung kerja tim mereka dengan membuat metrik yang membantu tim mengukur peningkatan kualitas mereka. Metrik DORA diidentifikasi oleh laporan survei Accelerate State of DevOps DORA. Metrik ini dirancang untuk membantu tim yang mempraktikkan pengiriman dan penerapan berkelanjutan menemukan area untuk peningkatan dan bagaimana kinerja mereka. Ini berbeda dari metrik rilis bulanan karena ini bukan tentang jumlah bug yang dirilis ke produksi, tetapi tentang seberapa cepat tim pulih dari kesalahan.

Pengiriman berkelanjutan dan penerapan berkelanjutan memberikan peluang bagi penguji untuk tumbuh dan mempelajari keterampilan baru. Jadi, penguji perlu memanfaatkan peluang saat tim mereka bertransisi ke pengiriman berkelanjutan dan penerapan berkelanjutan.