Tetapkan ulang “selesai” untuk memasukkan otomatisasi untuk pengiriman perangkat lunak

Posted on

Tetapkan ulang “selesai” untuk memasukkan otomatisasi untuk pengiriman perangkat lunak

Dalam mengejar tujuan ganda peningkatan kecepatan dan inovasi berkelanjutan, tim pengiriman telah meningkatkan upaya otomatisasi selama beberapa tahun terakhir. Otomatisasi pengujian berperan penting dalam membantu mempercepat siklus rilis, meningkatkan kualitas perangkat lunak, dan meningkatkan efisiensi di seluruh siklus hidup pengiriman perangkat lunak (SDLC). Namun, meskipun otomatisasi pengujian merupakan langkah kunci dalam membantu perusahaan mencapai desain dan penerapan berbasis cloud yang konsisten, hal ini juga menimbulkan teka-teki bagi tim perangkat lunak.

sang penulis: Sivakumar Anna, Infostretch, https://www.infostretch.com/

Siapa pun yang telah bekerja di lingkungan SDLC tradisional akan terbiasa dengan “definisi selesai”, titik di mana serangkaian persyaratan yang telah disepakati sebelumnya terpenuhi dan proyek atau kisah pengguna dapat dianggap selesai. pengembangan, bekerja dengan dua kecepatan, tim pengiriman memerlukan daftar periksa yang jelas untuk memastikan mereka tetap berada di jalur dengan desain yang diinginkan. Definisi yang dilakukan harus spesifik untuk cerita atau fitur tertentu, tetapi juga sesuai dengan tujuan bisnis organisasi yang lebih luas atau persyaratan keamanan dan kepatuhan.

Biasanya, otomatisasi pengujian tidak ditentukan sebagai bagian dari definisi selesai.

Tetapkan ulang

Cepat dan penuh energi

Fokus dalam sprint adalah kreativitas dan kecepatan. Karena otomatisasi pengujian bukan bagian dari pengarahan, sering kali diubah ke waktu berikutnya atau dibiarkan sampai akhir.

Namun, karena ekosistem perangkat lunak menjadi lebih kompleks, tim yang mengotomatiskan pengujian di akhir proses sebenarnya menyelamatkan diri dari masalah dalam bentuk hutang teknis. Dan seperti yang sering terjadi pada bug perangkat lunak, masalah yang ditemukan belakangan biasanya membutuhkan lebih banyak waktu untuk diungkap dan diperbaiki. Siapa pun yang harus bekerja lembur untuk memperbaiki kesalahan sistem yang mengejutkan tahu bahwa utang teknis adalah sesuatu yang benar-benar ingin kami minimalkan.

Namun, meski jelas tidak ada yang ingin membuat masalah yang akan merugikan mereka lagi di masa mendatang, ada alasan bagus mengapa utang teknis meningkat. Hutang teknis terjadi ketika tim mengambil jalan pintas untuk mencapai hasil dalam jangka waktu yang diinginkan. “Hutang” mengacu pada jumlah waktu yang dibutuhkan untuk mengolahnya di langkah berikutnya. Ini adalah bagian yang tak terhindarkan dari proses gesit karena ketika kita memprioritaskan kecepatan daripada kesempurnaan—pikirkan Produk Layak Minimum (MVP)—utang teknis akan menumpuk.

Automating-as-you-yo-go adalah pendekatan yang masuk akal untuk menghindari penyimpanan masalah dalam jangka panjang, tetapi tim perangkat lunak telah berjuang untuk mewujudkannya. Strategi otomatisasi sebagai kode ini tidak hanya membantu organisasi tetap ramping, gesit, dan efisien, tetapi jika diterapkan dengan benar, ini membantu tim memberikan kode berkualitas lebih baik yang memenuhi (atau melampaui) harapan inti semua orang. .

Bergeser ke kiri dengan otomatisasi pengujian

Agile mengedepankan eksperimen. Bukan lagi aktivitas yang dilakukan di akhir proses pengembangan, praktisi yang gesit sudah terbiasa bekerja sama dengan pakar pengujian manual. Karena proses pengujian semakin mendapat manfaat dari otomatisasi, masuk akal untuk menggeser otomatisasi pengujian ke kiri.

Namun, pada kenyataannya, banyak tim perangkat lunak memiliki kekurangan dalam hal otomatisasi dalam scrum sprint. Skeptisisme tentang otomatisasi dalam kecepatan berasal dari asumsi bahwa pekerjaan paling baik dilakukan saat produk selesai atau setidaknya stabil. Namun, redefinisi untuk menyertakan otomatisasi pengujian tidak hanya memungkinkan, tetapi dengan beberapa adaptasi dapat membantu tim memberikan hasil yang lebih efisien dengan menghindari proses berulang dan asumsi yang salah. Dan bertentangan dengan kepercayaan populer, otomatisasi dapat berjalan paralel dengan proses pengembangan.

Otomatisasi dalam Sprint beraksi

Salah satu penyedia layanan kesehatan dan asuransi terbesar di Amerika Serikat telah memasukkan otomatisasi dalam kecepatan sebagai bagian dari transformasi digitalnya. Itu menggunakan pendekatan ini untuk membangun tiga platform utamanya: platform manajemen inventaris farmasi, platform kolaborasi yang memungkinkan berbagi informasi antara departemen kesehatan yang berbeda, dan alat pasien-dokter yang diaktifkan dengan suara. Merancang, mengembangkan, dan memberikan solusi digital ini memungkinkan penyedia untuk mewujudkan peningkatan cepat dalam perawatan pasien dan pemanfaatan sumber daya, termasuk penghematan biaya 20 persen karena penghapusan proses manual.

Organisasi tidak memerlukan inisiatif digital besar untuk mendapatkan keuntungan dari otomatisasi pengujian Shift Left, mereka dapat menjadi lebih gesit secara signifikan dalam desain dan pengiriman perangkat lunak sehari-hari dengan berfokus pada langkah-langkah yang membawa otomatisasi ke dalam proses lebih awal. Keindahan dari pendekatan ini adalah, hanya dengan beberapa adaptasi, tim penguji dapat memasukkan otomatisasi pengujian sebagai bagian dari definisi mereka tentang selesai dalam praktik mereka.

1. Bawa masuk insinyur otomasi
Mulailah dengan mengundang teknisi otomasi ke sprint, berbicara dengan mereka, dan kemudian, berdasarkan diskusi tersebut, tetapkan definisi selesai yang menyertakan otomasi pengujian sebagai bagian dari daftar periksa. Jika ini terdengar jelas, itu karena, pada satu tingkat, memang demikian. Namun, dalam hal mendorong perubahan, budaya tim dapat membuat atau menghancurkan sebuah inisiatif. Ketika sebuah organisasi membawa spesialis otomasi ke dalam sebuah proyek sejak awal, ini memastikan bahwa para insinyur tersebut akan mendapatkan pemahaman yang jauh lebih rinci tentang visi, tujuan, dan tantangan karena mereka memiliki kesempatan untuk bekerja sama dengan pengembang. dan prospek produk, dan dengan menjadikan otomatisasi pengujian sebagai syarat untuk sukses, organisasi Anda mengirimkan sinyal yang jelas bahwa mereka serius dalam menghadirkan perangkat lunak yang lebih baik.

2. Berkolaborasi, lalu lepaskan
Mengundang pakar otomasi ke tahap pengembangan adalah langkah pertama, tetapi tidak menjamin kesuksesan. Kemudian terserah kepada insinyur dan pengembang otomasi untuk menemukan cara untuk bekerja secara produktif, yang berarti berbicara, memahami keahlian dan prioritas satu sama lain, menetapkan harapan, batasan, dan tujuan. Setelah mereka menguasai bentuk kolaborasi yang erat ini, bot uji harus memiliki informasi yang cukup untuk melakukan pekerjaan mereka bahkan tanpa memiliki semua kode akhir di tangan mereka. Dengan kata lain, kolaborasi erat pada awalnya memungkinkan aliran kerja paralel karena semua pihak yakin dengan apa yang sedang mereka kerjakan.

3. Pilih orang yang memiliki keahlian yang tepat untuk sprint
Insinyur otomasi mengotomatiskan, bukan? kesalahan! Setidaknya, itu hanya sebagian dari cerita. Jika Anda ingin memaksimalkan pengaruh mereka dalam lingkungan sprint, penting untuk memilih orang yang tidak hanya terlibat dalam bagian otomatisasi dari peran mereka, tetapi juga yang dapat berkolaborasi secara efektif, memahami cerita pengguna, dapat mendengar kebutuhan produk, serta menafsirkan dan merasa cukup. keterampilan dalam pengujian. Pengkodean sehingga Anda dapat bekerja dengan penguji dan pengembang tersebut.

4. Pilih alat yang tepat untuk pekerjaan itu
Tidak ada kekurangan pilihan dalam hal kerangka kerja otomasi. Pastikan untuk memilih salah satu yang sesuai dengan kebutuhan Anda. Misalnya, pertimbangkan bahwa itu harus mudah diakses oleh semua orang yang terlibat. Misalnya, pengujian otomatis harus ditulis secara fleksibel dan tanpa memerlukan UI. Terakhir, kemampuannya harus mendukung tujuan pengiriman organisasi Anda yang lebih luas (misalnya, pengujian berkelanjutan).

5. Seimbangkan prioritas otomasi
Ingat pengorbanan kecepatan/kesempurnaan saat mendesain MVP? Dalam lingkungan kecepatan, peserta harus selektif tentang apa yang mereka bangun, uji, dan otomatisasi. Prioritas strategis dalam skenario ini tidak hanya diinginkan, tetapi juga diperlukan untuk memastikan keberhasilan.

Dengan penyesuaian pada metodologi Agile yang biasa digunakan di sebagian besar perusahaan besar, kami menemukan bahwa otomatisasi dapat digabungkan pada titik yang jauh lebih awal di SDLC. Perubahan ini, baik oleh insinyur otomasi maupun tim pengembangan dan pengujian, mungkin memakan waktu lama, tetapi begitu ditetapkan, akan membawa banyak manfaat.

Otomatisasi pengujian adalah kekuatan yang terbukti untuk pengembangan dan pengiriman perangkat lunak. Peningkatan otomatisasi membantu meningkatkan cakupan pengujian, hasil perangkat lunak yang lebih baik, dan mempercepat siklus rilis, serta menghemat waktu dan biaya pengujian. Karena ekosistem perangkat lunak telah berkembang dalam kompleksitas dan jalur pipa yang berkelanjutan, SDLC menjadi tergantung pada pengujian otomatis.

Namun, tim perangkat lunak cenderung mengandalkan penerapan otomasi setelah tahap awal pengembangan. Ini bertentangan dengan prinsip pengembangan Agile dan pola pikir Shift Left. Memindahkan otomatisasi pengujian ke kiri, ke tahap Scrum, menghasilkan pengembangan perangkat lunak yang jauh lebih efisien, dan ini juga relatif mudah dicapai, dengan beberapa penyesuaian pada cara tim dibentuk dan cara mereka bekerja sama.

Tentang Penulis

Sivakumar Anna adalah Senior Enterprise QA Manager di Infostretch, sebuah perusahaan layanan profesional teknik digital. Dia memiliki lebih dari 25 tahun pengalaman transformasi teknologi dalam layanan otomasi di berbagai vertikal (BFSI, Layanan Kesehatan, E-Commerce, Platform Perangkat IoT, dan Otomasi Proses Bisnis).

Jika Anda ingin berkontribusi pada pengujian kualitas perangkat lunak dan konten jaminan kualitas perangkat lunak di situs web ini, hubungi SoftwareTestingMagazine.com.



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *