Apakah Pengujian merupakan bagian penting dari metodologi Agile?


24

Saya telah berada di banyak tim yang mencoba berlatih metodologi Agile dan seringkali tim-tim ini berpusat pada tes. Apakah menguji bagian penting dari mempraktikkan metodologi Agile atau hanya praktik XP yang telah dilakukan selama bertahun-tahun?


76
Pengujian adalah bagian penting dari setiap pengembangan perangkat lunak berkualitas.
Telastyn

2
kemungkinan duplikat Bisakah Anda Agile tanpa melakukan TDD (pengembangan yang digerakkan uji)? - jika Anda tidak setuju, beri tahu saya ...
Murph

11
Saya tidak setuju dengan duplikat. Pengujian lebih luas daripada TDD dan pertanyaan yang lebih luas memiliki jawaban yang berbeda.
Bart van Ingen Schenau

Saya setuju dengan @BartvanIngenSchenau. Tidak hanya menguji aktivitas yang jauh lebih luas daripada hanya melakukan TDD, tetapi pengujian TDD dan unit tidak sama. Saya terkejut begitu banyak orang bingung dua yang terakhir.
Andres F.

Mungkin telah dilipat ke dalam konsep "Definisi Selesai", yang dalam Agile / Scrum berarti itu tergantung pada konteks. Ketika Agile diterapkan untuk pemasaran, penjualan dll., Mereka tidak memiliki konsep yang sama dengan pengujian perangkat lunak, tetapi masih memiliki "definisi selesai". Untuk perangkat lunak, "definisi selesai" harus mempertimbangkan kualitas (baik kualitas kode yang terlihat maupun internal misalnya) dari hasil akhir, serta tingkat pengujian yang telah dilakukan.
rwong

Jawaban:


33

Pengujian sangat penting untuk gesit, terutama karena gesit didasarkan pada peningkatan bertahap: kesulitannya adalah terkadang sulit untuk melihat bagaimana perubahan saat ini akan memengaruhi kode lama Anda. Cara terbaik untuk yakin bahwa Anda belum merusak sesuatu adalah dengan mengujinya, dan untuk mengetahui BAGAIMANA mengujinya. Dengan cara itu Anda segera menemukan bug, bukan di ujung jalan ketika Anda lupa persis apa yang Anda lakukan ketika Anda menulis kode yang merusak beberapa fitur lama.

Alasannya berbeda dari pemrograman tipe desain top-down yang lebih tradisional adalah bahwa dalam lingkungan itu a) sangat sulit untuk diuji sampai Anda memiliki produk jadi b) secara teori Anda mempertimbangkan semua kriteria desain pada saat yang sama, dan jadi Anda cenderung membuat keputusan desain yang melanggar keputusan desain sebelumnya.


2
Penting juga bahwa perubahan inkremental di masa depan tidak merusak fungsi sebelumnya, dan unit test adalah cara mudah untuk memeriksanya.

1
Saya akan mengatakan pengujian sangat penting untuk pengembangan perangkat lunak .
Andres F.

@Snowman Testing! = Pengujian unit. Juga, pengujian unit! = TDD (untuk berjaga-jaga ...).
Andres F.

@AndresF. benar, saya biasanya menganggap unit testing menjadi bagian integral dari Agile karena alasan yang saya uraikan di atas. Kegagalan membaca.

8

Anda mungkin berbicara tentang pengujian otomatis, pengujian unit, tes integrasi dll. Ini lebih penting untuk gesit daripada pengujian manual (dengan penguji dan semacamnya) karena mereka terlalu lambat, sehingga tidak mungkin untuk menguji setiap perubahan kecil yang Anda buat. Karena lincah adalah tentang iterasi kecil yang cepat, memiliki tes yang memverifikasi kebenaran dalam hitungan detik atau menit, bukan jam atau hari, sangat berguna.


8

Jika Anda tidak memiliki tes, bagaimana Anda tahu kode Anda berfungsi?

Sunting: pernyataan bahwa tes tidak dapat membuktikan bahwa kode berfungsi gagal untuk mendefinisikan satu istilah penting, yaitu berfungsi . Apa artinya bagi suatu program untuk bekerja? Jika Anda mempertahankan istilah ini tidak jelas, maka tidak ada cara sama sekali untuk membuktikan atau memastikan bahwa program apa pun berfungsi. Pernah.

Di sisi lain, Anda dapat mendefinisikan karya sebagai "berperilaku sesuai dengan spesifikasi". Sekarang Anda tidak hanya dapat menggunakan tes untuk menunjukkan bahwa kode berfungsi, tetapi tes itu sendiri dapat berfungsi sebagai spesifikasi yang dapat dieksekusi dari perilaku kode Anda. Dengan kata lain, test suite yang ditulis dengan baik menentukan apa yang berfungsi .

Cara berpikir ini juga memaksa Anda untuk memeriksa kembali makna bug . Jika kode Anda lulus semua tes, maka tidak ada bug dalam kode. Jika, meskipun demikian, sistem tidak berperilaku sebagaimana mestinya, maka perilakunya tidak ditentukan dengan benar. Saya. E. bug ada di spec, ditentukan oleh tes.

Pendekatan pengembangan perangkat lunak ini memisahkan spesifikasi fungsional suatu sistem dari implementasinya, yang, menurut setiap buku rekayasa perangkat lunak di dunia, adalah hal yang sangat baik. Pada saat yang sama, pendekatan ini memastikan bahwa implementasi Anda selalu sesuai dengan spesifikasi fungsional.


13
kapan pelanggan berhenti melaporkan laporan bug? :-)
gbjbaanb

3
Anda bisa membuktikannya dengan benar. Rekayasa Perangkat Bersih Kamar sangat mirip dengan TDD, sebenarnya, tetapi hanya secara otomatis menghasilkan tes statistik yang dihasilkan dari spesifikasi dan bukti.
Jörg W Mittag

1
-1 - "Pengujian menunjukkan keberadaan, bukan tidak adanya bug."
Telastyn

@ Telastyn, Tidak memiliki tes menunjukkan keberadaan bug dengan hampir pasti. Di sisi lain, serangkaian tes yang ditulis dengan baik memberikan spesifikasi yang dapat dieksekusi dari apa yang kode Anda lakukan.
Dima

Saya tidak setuju, tetapi tidak ada jumlah pengujian yang membuktikan bahwa kode Anda berfungsi.
Telastyn

5

Tidak, itu tidak "perlu"

Prinsip - prinsip Agile tidak mengatakan apa pun secara langsung tentang pengujian.

Tapi ini sangat disarankan

Dengan komitmen Agile terhadap proses yang berkelanjutan, pengiriman berkelanjutan / bertahap, dan kualitas perangkat lunak, pengujian otomatis adalah solusi terbaik yang saat ini tersedia untuk sebagian besar proyek

Pengecualian (seperti dicatat oleh Jörg W Mittag) termasuk alat pengembangan yang terbukti benar, sistem pemrograman meta yang menghasilkan kode, dkk. Tetapi sistem semacam ini jarang terjadi.


4

Agile dan XP mencoba menghindari Big Design Up Front . Dalam BDUF, persyaratan dikumpulkan, spesifikasi formal dibuat, kemudian pengkodean dilakukan, kemudian pengujian dilakukan. Ini masuk akal untuk sistem yang didefinisikan dengan baik, misi dan kehidupan yang kritis seperti peralatan medis, wahana antariksa, dll.

Agile menghindari aliran ini karena tidak berfungsi dengan baik untuk masalah yang tidak terdefinisi dengan baik, misalnya "perubahan apa pun yang diminta klien untuk minggu ini". Kami masih memerlukan spesifikasi formal, jadi kami tahu apa yang harus dilakukan dan kapan kami selesai, tetapi alih-alih semacam dokumen tertulis, kami menggunakan kode dalam bentuk tes otomatis.

Tes unit otomatis cepat untuk menulis, cepat dijalankan dan sangat modular / dipisahkan. Ini membuat mereka cara cepat untuk secara resmi menentukan dan memeriksa persyaratan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.