Haruskah pengembang, penguji, dan pengguna bisnis memiliki satu skrip pengujian terpadu?

Dalam pengembangan, saya biasanya memiliki skrip pengujian sendiri yang akan mendokumentasikan data, skenario, dan langkah-langkah eksekusi yang saya rencanakan untuk diuji; ini adalah rencana pengujian dev saya. Ketika fungsionalitas telah digunakan untuk Uji, penguji mengujinya menggunakan skrip pengujian mereka sendiri yang mereka tulis. Di UAT, pengguna bisnis kemudian menguji menggunakan rencana pengujian mereka sendiri.

Dalam retrospeksi, sepertinya ini memberikan cakupan yang lebih baik, dengan tes dev memiliki campuran pengujian kotak hitam dan putih, sementara penguji dan pengguna bisnis fokus pada pengujian kotak hitam. Tetapi di sisi lain, ini memunculkan kasus uji berbeda yang hanya dieksekusi per tahap (mis. Beberapa kasus yang dianggap penguji hanya dieksekusi pada tahap Uji) dan ia ingin dev melewatkannya, yang membuatnya menjadi temuan / bug .

Apakah layak mengkonsolidasikan skrip pengujian dari awal? Dengan demikian menggunakan satu skrip pengujian terpadu, atau apakah agak sulit untuk melakukan ini di muka?

QA pertama bukan Tes. Jika departemen QA Anda tidak terlibat dalam seluruh proses pengembangan, mereka adalah Tes, bukan QA. QA ketika melakukan pekerjaannya, memberikan jaminan kualitas, paling-paling Tes menunjukkan kurangnya kualitas, tetapi tidak dapat membuktikan kualitas ada - yaitu Uji menunjukkan QA telah gagal, tetapi tidak dapat menunjukkan mereka telah berhasil, jadi Tes dan QA tidak boleh menjadi departemen yang sama.

Saya percaya cara terbaik adalah membuat masing-masing kelompok mengelola tes mereka sendiri, karena memberikan cakupan yang lebih baik. Namun, setiap tim harus memulai pengujian sesegera mungkin. Ini berarti bahwa UAT dimulai segera setelah ada sesuatu yang dapat digunakan oleh Pengguna, Tes akan dimulai segera setelah bagian yang mereka uji siap, dll. Ini mencegah keterlambatan menemukan kasus uji yang berbeda. Ini mungkin berarti beberapa rejigging model kerja Anda, seperti yang sering dilakukan UAT dan Test untuk bekerja pada produk lengkap dan perlu pelatihan dalam menguji sebagian hasil lengkap. Ini bisa lebih mahal kecuali alur kerja tidak disiplin dan pengembang "Lengkap" berarti Lengkap.

QA harus mengawasi hal ini, bersama dengan langkah-langkah kualitas lainnya, untuk memastikan proses tidak hanya memberikan hasil kualitas yang diinginkan, tetapi juga pada tingkat efisiensi yang tepat.

Sunting: Referensi pertanyaan asli untuk QA telah dihapus, karenanya jawaban ini sekarang muncul OT.

Kami menggunakan UAT sejak awal.

Ini bertindak sebagai referensi universal dan saya pikir itu berfungsi dengan baik. Meskipun mungkin ada skrip pengujian yang hanya digunakan oleh Devs atau Penguji untuk komponen yang lebih kecil, arah pengujian selalu mengarah ke satu target yang disatukan. Pada akhirnya, UAT adalah satu-satunya yang penting sehingga Anda bisa menjadikannya fokus di awal.

Melakukan UAT sejak awal juga memiliki manfaat tambahan. Ini benar-benar menghapus ambiguitas antara harapan pelanggan dan harapan Anda sendiri.

Mereka tidak memerlukan skrip uji unifed karena hal-hal yang mereka uji dan cara mereka melakukan tes sering dianggap berbeda, yang mereka butuhkan adalah persyaratan terpadu yang semua pihak kerjakan. Jika UAT dan QA menguji hal-hal yang tidak pernah dipikirkan pengembang, maka sudah saatnya untuk melihat persyaratan.

Saya setuju, bahwa memiliki skrip pengujian terpadu untuk devs, penguji dan pengguna bisnis akan menyenangkan untuk dimiliki tetapi saya percaya itu tidak mungkin tanpa banyak upaya di mana biaya melebihi penghunian sebagai manfaat.

Alasan kesulitannya adalah bahwa konten database di setiap sistem berbeda dan tes biasanya sangat tergantung pada konten database. pendekatan kami untuk "tes terpadu" adalah bahwa setiap sistem juga mendapatkan database uji tambahan dan ada skrip untuk membuat db dari awal. skrip uji dijalankan terhadap testdb di mana kontennya standar.

Di dunia yang sempurna pengembang harus memiliki unit test (xUnit), penguji - tes integrasi otomatis (Selenium) dan pengguna bisnis - tes penerimaan (FIT). Mereka dapat memiliki akses ke tes satu sama lain.

Itu sangat tergantung pada proyek. Dalam beberapa kasus, tes terpadu, tim QA dan UAT yang bertemu untuk membahas temuan bisa sangat bermanfaat. Ini menghemat duplikasi upaya pengujian, dan memastikan bahwa semua pihak memiliki pemahaman yang lebih jelas tentang kebutuhan bisnis melalui skrip UAT. Di sisi lain, tergantung pada kompleksitas proyek, mungkin lebih masuk akal untuk memiliki QA input dan output sebelum menguji contoh bisnis. Untuk pengembangan sistem yang dikembangkan di rumah, QA awal akan menjadi keharusan sebelum penerimaan pengguna. Untuk implementasi out-of-the-box, tim pengujian terpadu akan paling masuk akal.