Berkembang dengan percaya diri tanpa lingkungan pengembangan yang nyata

12

Saya baru-baru ini disewa untuk proyek yang melibatkan bekerja dengan dan di sekitar beberapa sistem "perusahaan" pihak ketiga. Karena apa yang saya bayangkan akan menjadi biaya astronomi dan upaya yang diperlukan untuk membangun replika lingkungan produksi yang cukup setia, prospek memiliki lingkungan pengembangan nyata tampak semakin tipis.

Ini tentu saja tidak ideal. Sisi baiknya, saya membayangkan pasti ada orang di luar sana yang dengan aman menguji dan menggunakan perangkat lunak ke dalam lingkungan yang tidak dapat ditiru seperti ini, dan saya mungkin dapat mengikuti jejak mereka.

Bagaimana mereka yang secara efektif menghadapi situasi semacam ini melakukannya?

testing development-process

— Jason Swett
sumber

1

Virtualisasi, memiliki "mirip dengan" lingkungan dll ... Pada dasarnya, cobalah untuk mereplikasi apa yang Anda bisa, dalam skala yang lebih kecil, untuk setidaknya mencakup sebagian besar "bagian yang bergerak" dari sistem.

— Oded

6

Anda harus mengandalkan kebenaran API sistem perusahaan dan melakukan banyak pengujian integrasi, mungkin dengan beberapa akun pengujian.

— Robert Harvey

@RobertHarvey sudah mati di sini. Seseorang harus menguraikan ini dalam jawaban tetapi ini persis apa yang Anda butuhkan. Dengan tidak adanya lingkungan untuk pengujian sistem secara manual, yang dapat Anda lakukan adalah menguji kode secara otomatis.

— Jimmy Hoffa

1

Oke, jadi mungkin titik pengambilan yang baik adalah bahwa jika Anda tidak dapat memiliki lingkungan pengembang penuh, akun pengujian dalam produksi dapat menjadi hal terbaik berikutnya.

— Jason Swett

9

Ini terjadi setiap saat di dunia nyata. Saya kenal seorang pria yang menulis aplikasi yang mengontrol rumah kaca pertanian raksasa - ventilasi, pemanas, kontrol kelembaban, apa saja. Dia tidak memiliki "rumah kaca uji", tetapi dia memiliki program simulator yang disediakan oleh perusahaan yang membangun sistem perangkat keras yang sebenarnya. Jika kode bekerja dengan benar dengan simulator, itu dianggap bekerja dengan benar dengan peralatan nyata. Pada kesempatan yang jarang, simulator ternyata salah, tetapi itulah masalah perusahaan perangkat keras rumah kaca, karena tidak disimulasikan dengan benar.

— Ross Patterson
sumber

OP tampaknya tidak memiliki jaminan 'simulator'. Juga, dalam kasus Anda, majikan kolega Anda mungkin dapat meminta kompensasi jika simulator gagal. Apa yang bisa OP lakukan dalam situasi serupa? Mengganggu perusahaan asuransi?

— K.Steff

4

Jika OP tidak memiliki simulator, ia perlu mendapatkan satu - mohon / mencuri / meminjam / membangun - tidak terlalu penting. Sebagus apa simulator itu - itulah sesuatu yang perlu dia putuskan, dan jika dia merasa perlu, dia bisa / harus berbicara dengan perusahaan asuransi tentang hal kecil yang disebut ganti rugi.

— mattnz

3

Ini adalah situasi ketika dokumentasi API, dokumen kontrol antarmuka, dan emulator adalah yang terpenting. Di perusahaan tempat saya bekerja sebelumnya, ini benar-benar terjadi. Ini akan sering terjadi dalam suatu proyek selama fase integrasi tertentu di mana satu segmen sudah siap, tetapi yang lain sudah ketinggalan, ada fitur yang sedang dikerjakan, atau karena alasan lain mereka tidak dapat menggunakan versi terbaru dari segmen mereka ke sistem pengujian kami. Jadi, ya kami benar-benar memiliki replika yang setia dari lingkungan produksi kami yang kami uji; Namun, dalam praktiknya semua segmen tidak pernah siap sesuai jadwal, tetapi antarmuka telah disepakati dan dikunci sebelum pengembangan dimulai, dan emulator telah dibuat yang sebagian besar dapat meniru perilaku segmen lainnya.

Seperti jawaban lain yang disebutkan emulator adalah apa yang akan memungkinkan pengujian berlangsung sebelum penyebaran. Emulator yang baik; Namun, tergantung pada antarmuka dan dokumentasi yang didefinisikan dengan baik.

— Fred Thomsen
sumber

1

Saya dalam situasi seperti itu sepanjang waktu.

Anda tentu tidak perlu berinteraksi dengan seluruh aplikasi, tetapi mungkin beberapa antarmuka. Pastikan Anda telah mengkonfirmasi dan memerinci dokumentasi antarmuka, kemudian atur tiruan antarmuka ini hanya untuk memverifikasi bahwa kode Anda yang ditambahkan / diubah berfungsi seperti yang Anda inginkan.

Anda juga bisa melakukan hybrid. Cobalah untuk mereplikasi bagian-bagian yang agak mudah Anda lakukan, kemudian "hubungkan" ke sistem yang sebenarnya (jika ini mungkin dalam situasi Anda). Saya telah melakukannya dengan beberapa keberhasilan - dalam beberapa kasus di mana logika saya dan perangkat lunak server dijalankan secara lokal, tetapi saya masih memiliki koneksi ke sistem ERP nyata untuk memverifikasi invoice dll. Tidak ideal, tetapi hal-hal jarang terjadi.

Mengingat Anda hanya memiliki sistem produksi untuk bekerja - perhatikan bahwa Anda tidak dapat hanya menghitung waktu pengembangan yang dihemat untuk menyiapkan replika, tetapi Anda harus memperhitungkan risiko bisnis menggunakan kode yang sebagian besar belum diuji dengan data bisnis langsung. Kode Anda AKAN kurang dapat diandalkan dibandingkan kode yang diuji terhadap replika. Bisakah sistem dimatikan untuk beberapa waktu? Dapatkah mereka dipulihkan jika terjadi korupsi data? Berapa harganya?

Praktik terbaik dalam perusahaan adalah memasang replika (atau mungkin lebih dari satu) produksi pada saat lingkungan produksi sedang disiapkan. Pada saat itu, biaya tambahan tidak akan sebesar itu.

— Petter Nordlander
sumber

1

Sistem kami bekerja dengan sejumlah sistem eksternal besar. Kami menggabungkan pendekatan berikut saat mengujinya jika kami tidak memiliki pengaturan ujung ke ujung yang lengkap:

Rekam-ulang data nyata. Rekam data nyata (permintaan / tanggapan dari sistem eksternal nyata), parametrize jika perlu, dan putar ulang
Bangun atau beli simulator yang bertindak sebagai sistem eksternal
DSL untuk pembuatan data-uji. Untuk sistem berbasis data, tulis DSL tingkat tinggi untuk menghasilkan data uji.

— dzieciou
sumber