Bagaimana pengujian perangkat lunak dilakukan pada startup teknologi?

10

Saya telah melihat banyak artikel penelitian dan blog teknologi yang membanggakan manfaat pengujian perangkat lunak. Saya sudah yakin akan hal itu. Tetapi karena semua penelitian pengujian perangkat lunak dilakukan oleh perusahaan perangkat lunak besar, saya tidak percaya mereka benar-benar berlaku untuk startup. Karena startup memiliki kebutuhan dan kendala yang berbeda dibandingkan dengan perusahaan perangkat lunak besar.

Jadi ini menimbulkan pertanyaan. Haruskah startup teknologi menulis tes otomatis? Jika demikian, apakah mereka dilakukan dengan cara yang sama dengan perusahaan perangkat lunak besar? (tes asap, tes regresi, dll.) Yang terbaik adalah jika Anda dapat merujuk beberapa artikel penelitian tentang hal ini .. karena saya tidak dapat menemukannya sendiri.

(Saya harus mengakui bahwa meskipun saya masih awal dalam karir saya, tetapi saya belum melihat startup yang secara serius berkomitmen untuk menulis tes otomatis)

testing startup

— ming_codes
sumber

5

Saya bergabung dengan start-up kecil 10-yo, dan saya adalah orang pertama yang benar-benar menambahkan tes yang berjalan di malam hari. Bukan karena saya jenius, tetapi ini adalah pertama kalinya manajer (juga pembuat kode) mengakui bahwa sudah waktunya menambahkan mereka, dan bahwa mereka akhirnya memiliki tenaga. Strat-up sering harus bertahan dulu, dan sempurna kemudian. Memang, start-up ini dimulai oleh non-techies, jadi fitur ini harus "dimasukkan".

— Pekerjaan

5

Startup berusia 10 tahun ...?

— pap

Dilbert berkata : "Jika praktik terbaik diadopsi oleh semua orang di industri, maka praktik terbaik menjadi biasa-biasa saja." Saya kira itu agak benar, heh.

— ming_codes

10 tahun start-up ... mereka harus menggunakan Java: 3 thn desain + 7 pengembangan :) hanya bercanda (Saya seorang Jawa btw dev)

— nuvio

11

Selalu ada konflik antara apa yang harus dilakukan dan apa yang secara realistis kita punya waktu. Ya, banyak startup mengabaikan pengembangan yang didorong oleh pengujian dan pengujian otomatis untuk mengurangi waktu istirahat agar proyek dapat berjalan dan berjalan.

Situs jejaring sosial dan perusahaan aplikasi seluler adalah gelembung besar sekarang, dan mereka sangat kompetitif. Terkadang perbedaan antara tayang dalam 4 bulan versus 5 bulan berarti Anda Kalah.

Waktu untuk memasarkan adalah kuncinya, dan kemudian jika kesuksesan terjadi maka sekarang saatnya untuk skala, maka akan ada banyak waktu untuk memperbaiki perangkat lunak Anda yang belum diuji menjadi sesuatu yang berharga.

— maple_shaft
sumber

Namun, waktu untuk memasarkan sedikit mitos. Peserta yang terlambat masuk ke pasar dapat menerbangkan pemain yang ada: friendster> myspace> facebook.

— Joeri Sebrechts

@ JoeriSebrechts Saya membaca artikel yang menarik tentang perkembangan perangkat lunak dan bagaimana kaitannya dengan keberhasilan pendatang yang terlambat. Ada beberapa variabel yang berperan, periode aman untuk peserta yang terlambat dengan solusi yang serupa sama dengan jumlah waktu untuk basis pengguna perangkat lunak untuk berubah dari Early Adopters ke General Users. Solusi serupa tentu saja berarti fitur yang mirip dan tidak melanggar dibandingkan dengan peserta pertama ke pasar (Misalnya. Facebook adalah terobosan dibandingkan dengan MySpace). Setelah massa kritis dari Early Adopters tercapai, pengguna umum mulai bermigrasi.

— maple_shaft

12

Pengujian perangkat lunak bukan agama. Itu hanya ide yang sangat bagus.

Anda mengatakan Anda tidak memiliki tenaga untuk menulis tes sekarang? Baiklah. 6 minggu dari sekarang, apakah Anda akan memiliki tenaga untuk menemukan bug yang merusak aplikasi Anda, yang akan segera ditemukan jika Anda memiliki tes yang tepat di tempat?

Terlalu banyak pengujian dapat memperlambat pengembangan. Terlalu sedikit pengujian juga dapat memperlambatnya. Anda harus menemukan keseimbangan yang tepat, dan biasanya sulit untuk mengatakan di mana itu. Dan semua ini tidak khusus untuk perusahaan besar atau kecil.

— Mike Baranczak
sumber

4

Selama bertahun-tahun, ketika bekerja di perusahaan kecil dan perusahaan baru, saya berada di bawah kesalahpahaman bahwa saya "tidak punya cukup waktu untuk menulis unit test untuk kode saya" .

Ketika saya menulis tes, itu adalah hal-hal berat yang membuat saya berpikir bahwa saya seharusnya hanya menulis tes unit ketika saya tahu itu diperlukan.

Baru-baru ini saya didorong untuk menggunakan Test Driven Development dan saya menemukan ini sebagai wahyu yang lengkap .

Saya sekarang sangat yakin bahwa saya "tidak punya waktu untuk tidak menulis unit-test" .

Dalam pengalaman saya, dengan mengembangkan dengan pengujian dalam pikiran Anda berakhir dengan antarmuka yang lebih bersih, kelas & modul yang lebih fokus dan umumnya lebih SOLID , kode diuji.

Setiap kali saya bekerja dengan kode lama yang tidak memiliki tes unit, dan harus menguji sesuatu secara manual, saya terus berpikir "ini akan jauh lebih cepat jika kode ini sudah memiliki unit test" . Setiap kali saya harus mencoba dan menambahkan fungsionalitas unit test ke kode dengan kopling tinggi, saya terus berpikir "ini akan jauh lebih mudah jika telah ditulis dengan cara de-coupled" .

Jika ada satu hal yang saya temukan selama bertahun-tahun, jika Anda bekerja pada permulaan, Anda harus gesit , dan tidak hanya dalam arti metodologi pengembangan perangkat lunak . Bagi saya TDD adalah alat penting yang memungkinkan memulai dan tetap gesit .

— Mark Booth
sumber

1

Ini bukan tentang siapa yang harus melakukan pengujian perangkat lunak, Pengujian perangkat lunak itu semacam filosofi pengembangan perangkat lunak. Pengujian Perangkat Lunak menetapkan dasar kualitas perangkat lunak yang baik, dan di awal, kualitas perangkat lunak adalah bonus ketika akuisisi oleh perusahaan besar sudah dekat;)

— Francisco Valdez
sumber

1

Praktik terbaik bersifat luas di industri, apakah Anda menjadikan nenek situs web atau membuat sistem panduan untuk satelit. Mereka harus selalu diikuti oleh mereka yang ingin menganggap diri mereka profesional, itu sebabnya mereka disebut praktik TERBAIK.

— Ryathal
sumber

Anda mungkin terkejut mendengar bahwa praktik terbaik tidak selebar industri itu. thedailywtf.com

— Gary Willoughby

@Gary lebih merupakan industri yang luas dalam teori, atau bagian dari dunia utopis di mana proyek memiliki garis waktu yang realistis dan html memiliki makna semantik dan manajer mengakui bahwa mereka tidak memiliki pengetahuan teknis yang akan membantu mereka membuat keputusan yang lebih baik ...

— Ryathal

"Praktik Terbaik" biasanya berarti melakukan hal-hal seperti yang dilakukan orang lain, menghasilkan hasil rata-rata. Perusahaan yang didirikan rata-rata tidak cukup baik, tetapi startup teknologi rata-rata tidak cukup untuk crash secara spektakuler.

— David Thornley

1

@ Davidvidhorn - Tidak, saya pikir "Praktik Terbaik" adalah apa yang kebanyakan orang percaya harus mereka lakukan, apakah mereka punya waktu, energi atau persetujuan manajemen untuk melakukannya. * 8 ')

— Mark Booth

@ Mark Booth: Biasanya, ketika saya sudah mendengar frasa, itu berarti apa yang saya katakan. YMMV, tentu saja. Namun, Ryathal merujuk pada dunia di mana proyek memiliki jadwal yang realistis, dan itu tidak selalu mungkin dalam bisnis. Memiliki produk yang keluar dua bulan terlambat mungkin tidak penting atau berakibat fatal (terutama untuk startup yang mungkin berisiko kehabisan uang), dan sering kali ada kasus bisnis yang kuat untuk mendapatkan sesuatu yang sebagian besar berhasil di luar pintu ASAP. Saya merasa sulit untuk percaya pada "praktik terbaik" yang dapat menghancurkan perusahaan.

— David Thornley

1

Ya, startup terkadang mengambil jalan pintas dan tidak memaksakan pengujian yang tepat. Terkadang ini tepat (untuk proyek yang cukup kecil atau ketika waktu / uang sangat penting)

Ini bukan eksklusif untuk startup. Salah satu pemasok kami, kontraktor TI, bahkan memiliki lingkungan pengujian. Semuanya dilakukan langsung untuk hidup dan ini adalah perusahaan perangkat lunak multi-nasional besar (menakutkan!)

— Tom Squires
sumber

1

Haruskah mereka Iya. Apakah mereka melakukannya dalam praktik, tidak sesering yang seharusnya.

Alasan paling umum yang diberikan adalah kurangnya sumber daya yang mencakup waktu pengembang, biaya mempekerjakan penguji khusus atau paruh waktu, biaya menyiapkan lingkungan pengujian dan sebagainya. Anda bahkan dapat menemukan alasan-alasan ini dalam pengaturan perusahaan yang besar serta memulai yang kecil.

Melihat dengan cara lain, pengujian adalah salah satu hal termudah untuk memotong dari jadwal pengembangan, terutama yang dengan tekanan waktu yang sangat ketat dan / atau tekanan biaya untuk menghasilkan hasil yang terlihat. Seiring dengan pekerjaan desain yang terperinci, itu dianggap 'halus' oleh banyak manajer dan tempat pertama mereka akan mengatakan "memotongnya sehingga kita dapat membuat jadwal dan anggaran kita bekerja" diikuti oleh "Mengapa Anda tidak coding?".

Di beberapa perusahaan, akan ada seseorang yang melakukan push testing. Biasanya ini adalah pengembang yang dipekerjakan dan biasanya mereka akan menjadi seseorang yang berpengalaman dan mungkin seseorang yang memiliki kepentingan keuangan di perusahaan. Perusahaan yang memulai dengan "DNA" ini mungkin akan melakukan pengujian sejak awal.

— jfrankcarr
sumber