Pengujian Integrasi: Apa itu, Jenis, Contoh Top Down & Bottom Up

Pengujian Integrasi: Apa itu, Jenis, Contoh Top Down & Bottom Up

Apa itu Pengujian Integrasi?

PENGUJIAN INTEGRASI didefinisikan sebagai jenis pengujian di mana modul perangkat lunak diintegrasikan secara logis dan diuji sebagai kelompok. Proyek perangkat lunak tipikal terdiri dari beberapa modul perangkat lunak, yang dikodekan oleh pemrogram yang berbeda. Tujuan dari tingkat pengujian ini adalah untuk mengekspos kerusakan dalam interaksi antara modul-modul perangkat lunak ini ketika mereka terintegrasi

 Pengujian Integrasi berfokus pada memeriksa komunikasi data di antara modul-modul ini. Oleh karena itu juga disebut sebagai  ‘I & T’  (Integration and Testing),  ‘String Testing‘ dan kadang-kadang ‘Thread Testing‘ .

Mengapa Pengujian Integrasi?

Meskipun setiap modul perangkat lunak diuji unit, cacat tetap ada karena berbagai alasan seperti

• Modul, secara umum, dirancang oleh pengembang perangkat lunak individual yang pemahaman dan logika pemrogramannya mungkin berbeda dari programmer lain. Pengujian Integrasi menjadi perlu untuk memverifikasi modul perangkat lunak bekerja dalam kesatuan
• Pada saat pengembangan modul, ada kemungkinan besar perubahan dalam persyaratan oleh klien. Persyaratan baru ini mungkin tidak diuji unit dan karenanya Pengujian integrasi sistem menjadi perlu.
• Antarmuka modul perangkat lunak dengan database bisa keliru
• Antarmuka perangkat keras eksternal, jika ada, bisa keliru
• Penanganan pengecualian yang tidak memadai dapat menyebabkan masalah.

Contoh Kasus Uji Integrasi

Integration Test Case berbeda dari test case lain dalam arti berfokus terutama pada antarmuka & aliran data / informasi antar modul . Di sini prioritas diberikan untuk tautan pengintegrasian daripada fungsi unit yang sudah diuji.

Contoh Kasus Uji Integrasi untuk skenario berikut: Aplikasi memiliki 3 modul yaitu ‘Halaman Masuk’, ‘Kotak Surat’ dan ‘Hapus email’ dan masing-masing terintegrasi secara logis.

Di sini tidak banyak berkonsentrasi pada pengujian Halaman Login karena sudah dilakukan di Unit Testing . Tetapi periksa bagaimana tautannya ke Halaman Kotak Surat.

Demikian pula Kotak Surat: Periksa integrasinya ke Modul Hapus Surat.

ID Kasus Uji	Tujuan Uji Kasus	Deskripsi Test Case	Hasil yang diharapkan
1	Periksa tautan antarmuka antara modul Login dan Kotak Surat	Masukkan kredensial masuk dan klik tombol Login	Untuk diarahkan ke Kotak Surat
2	Periksa tautan antarmuka antara Kotak Surat dan Hapus Modul Surat	Dari Kotak Surat pilih email dan klik tombol hapus	Email yang dipilih akan muncul di folder Dihapus / Sampah

Pendekatan, Strategi, Metodologi Pengujian Integrasi

Rekayasa Perangkat Lunak mendefinisikan berbagai strategi untuk melaksanakan pengujian Integrasi, yaitu.

•  Pendekatan Big Bang:
•  Pendekatan Tambahan: yang selanjutnya dibagi menjadi sebagai berikut:
  •  Pendekatan atas ke bawah (Top Down)
  •  Pendekatan dari Bawah ke Atas (Bottom Up)
  •  Sandwich Approach – Kombinasi Top Down dan Bottom Up

Di bawah ini adalah strategi yang berbeda, cara mereka dieksekusi dan keterbatasannya serta keuntungannya.

Pendekatan Big Bang:

Di sini semua komponen terintegrasi bersamaan sekaligus diuji.

Keuntungan:

• Nyaman untuk sistem kecil.

Kekurangan:

• Lokalisasi kesalahan sulit.
• Mengingat banyaknya antarmuka yang perlu diuji dalam pendekatan ini, beberapa tautan antarmuka yang akan diuji dapat dilewatkan dengan mudah.
• Karena pengujian Integrasi dapat dimulai hanya setelah “semua” modul dirancang, tim pengujian akan memiliki waktu lebih sedikit untuk dieksekusi dalam fase pengujian.
• Karena semua modul diuji sekaligus, modul kritis berisiko tinggi tidak diisolasi dan diuji berdasarkan prioritas. Modul periferal yang berurusan dengan antarmuka pengguna juga tidak diisolasi dan diuji berdasarkan prioritas.

Pendekatan Tambahan

Dalam pendekatan ini, pengujian dilakukan dengan menggabungkan dua atau lebih modul yang terkait secara logis . Kemudian modul terkait lainnya ditambahkan dan diuji untuk berfungsi dengan benar. Proses berlanjut hingga semua modul bergabung dan diuji dengan sukses.

Pendekatan inkremental, pada gilirannya, dilakukan oleh dua Metode berbeda:

• Bottom Up
• Top Down

Apa itu Stubs and Driver?

Pendekatan inkremental dilakukan dengan menggunakan program dummy yang disebut Stubs and Drivers . Stubs dan Driver tidak menerapkan seluruh logika pemrograman modul perangkat lunak tetapi hanya mensimulasikan komunikasi data dengan modul panggilan.

Stubs : Disebut oleh Modul yang sedang diuji.

Driver : Memanggil Modul yang akan diuji.

Integrasi Bottom Up

Dalam strategi bottom-up, setiap modul di tingkat bawah diuji dengan modul yang lebih tinggi hingga semua modul diuji. Dibutuhkan bantuan Driver untuk pengujian

Representasi Diagram :

Keuntungan:

• Lokalisasi kesalahan lebih mudah.
• Tidak ada waktu yang terbuang untuk menunggu semua modul dikembangkan tidak seperti pendekatan Big Bang

Kekurangan:

• Modul penting (pada tingkat atas arsitektur perangkat lunak) yang mengontrol aliran aplikasi diuji terakhir dan mungkin rentan terhadap cacat.
• Prototipe awal tidak dimungkinkan

Integrasi Top-down:

Dalam pendekatan Top to down, pengujian dilakukan dari atas ke bawah mengikuti aliran kontrol sistem perangkat lunak.

Membutuhkan bantuan stubs untuk pengujian.

Representasi Diagram:

Keuntungan:

• Lokalisasi kesalahan lebih mudah.
• Kemungkinan untuk mendapatkan prototipe awal.
• Modul Kritis diuji berdasarkan prioritas; cacat desain utama dapat ditemukan dan diperbaiki terlebih dahulu.

Kekurangan:

• Membutuhkan banyak Stubs.
• Modul pada tingkat yang lebih rendah diuji secara tidak memadai.

Integrasi Hybrid / Sandwich

Dalam strategi sandwich / hybrid adalah kombinasi dari pendekatan Top Down dan Bottom up. Di sini, modul teratas diuji dengan modul yang lebih rendah pada saat yang sama modul yang lebih rendah diintegrasikan dengan modul atas dan diuji. Strategi ini memanfaatkan stubs serta driver.

Bagaimana cara melakukan Pengujian Integrasi?

Prosedur pengujian Integrasi terlepas dari strategi pengujian Perangkat Lunak (dibahas di atas):

1. Mempersiapkan Rencana Tes Integrasi
2. Desain Skenario, Kasus, dan Skrip Uji.
3. Melaksanakan uji Kasus diikuti dengan melaporkan cacat.
4. Melacak & menguji ulang cacat.
5. Langkah 3 dan 4 diulangi sampai penyelesaian Integrasi berhasil.

Deskripsi Singkat Rencana Tes Integrasi:

Terdiri beberapa hal berikut:

• Metode / Pendekatan untuk pengujian (seperti dibahas di atas).
• Cakupan dan luar cakupan Item Pengujian Integrasi.
• Peran dan Tanggung Jawab.
• Prasyarat untuk pengujian Integrasi.
• Lingkungan pengujian.
• Rencana Risiko dan Mitigasi.

Kriteria Masuk dan Keluar dari Pengujian Integrasi

Kriteria Masuk dan Keluar ke fase pengujian Integrasi dalam model pengembangan perangkat lunak apa pun

Kriteria Entri:

• Komponen / Modul Yang Diuji Unit
• Semua bug yang diprioritaskan Tinggi diperbaiki dan ditutup
• Semua Modul menjadi kode yang diselesaikan dan diintegrasikan dengan sukses.
• Rencana Tes Integrasi, uji kasus, skenario yang akan ditandatangani dan didokumentasikan.
• Lingkungan Uji yang Diperlukan harus disiapkan untuk pengujian Integrasi

Kriteria Keluar:

• Pengujian Aplikasi Terintegrasi yang berhasil.
• Kasus Uji yang dieksekusi didokumentasikan
• Semua bug yang diprioritaskan Tinggi diperbaiki dan ditutup
• Dokumen teknis yang akan dikirim diikuti oleh Notes rilis.

Praktik / Pedoman Terbaik untuk Pengujian Integrasi

• Pertama, tentukan Strategi Uji Integrasi yang dapat diadopsi dan kemudian menyiapkan kasus uji dan data uji yang sesuai.
• Pelajari desain Arsitektur Aplikasi dan identifikasi Modul Kritis. Ini perlu diuji berdasarkan prioritas.
• Dapatkan desain antarmuka dari tim Arsitektur dan buat kasus uji untuk memverifikasi semua antarmuka secara detail. Antarmuka ke basis data / aplikasi perangkat keras / perangkat lunak eksternal harus diuji secara terperinci.
• Setelah uji kasus, data uji yang memainkan peran penting.
• Selalu siapkan data tiruan, sebelum dieksekusi. Jangan memilih data uji saat menjalankan kasus uji.

Tutorial Pengujian Unit: Apa itu, Jenis, Alat, Contoh

Tutorial Pengujian Unit: Apa itu, Jenis, Alat, Contoh

Apa itu Unit Testing?

UNIT TESTING adalah jenis pengujian perangkat lunak di mana masing-masing unit atau komponen suatu perangkat lunak diuji. Tujuannya adalah untuk memvalidasi bahwa setiap unit kode perangkat lunak melakukan seperti yang diharapkan. Unit Testing dilakukan selama pengembangan (fase pengkodean) aplikasi oleh pengembang. Unit testing mengisolasi bagian kode dan memverifikasi kebenarannya. Unit dapat berupa fungsi, metode, prosedur, modul, atau objek individual.

Dalam SDLC, STLC, V Model, pengujian unit adalah pengujian tingkat pertama yang dilakukan sebelum pengujian integrasi. Unit testing adalah teknik pengujian WhiteBox yang biasanya dilakukan oleh pengembang. Padahal, dalam dunia yang praktis karena krisis waktu atau keengganan pengembang untuk menguji, insinyur QA juga melakukan pengujian unit.

Mengapa Unit Testing?

Terkadang pengembang perangkat lunak berupaya menghemat waktu dengan melakukan pengujian unit minimal. Ini adalah mitos karena melewatkan pengujian unit mengarah ke biaya perbaikan cacat yang lebih tinggi selama pengujian sistem, pengujian Integrasi dan bahkan Pengujian Beta setelah aplikasi selesai. Pengujian unit yang tepat dilakukan pada tahap pengembangan menghemat waktu dan uang pada akhirnya. Di sini, adalah alasan utama untuk melakukan pengujian unit.

Tingkat Pengujian Unit

1. Tes unit membantu untuk memperbaiki bug di awal siklus pengembangan dan menghemat biaya.
2. Ini membantu pengembang untuk memahami basis kode dan memungkinkan mereka untuk membuat perubahan dengan cepat
3. Tes unit yang baik berfungsi sebagai dokumentasi proyek
4. Tes unit membantu penggunaan kembali kode. Migrasikan kode Anda  dan tes Anda ke proyek baru Anda. Tweak kode hingga tes berjalan lagi.

Cara melakukan Pengujian Unit

Unit Testing terdiri dari dua jenis

• Manual
• Otomatis

Pengujian unit umumnya otomatis tetapi masih dapat dilakukan secara manual. Rekayasa Perangkat Lunak tidak mendukung satu sama lain tetapi otomatisasi lebih disukai. Pendekatan manual untuk pengujian unit dapat menggunakan dokumen petunjuk langkah demi langkah.

Di bawah pendekatan otomatis-

• Pengembang menulis bagian kode dalam aplikasi hanya untuk menguji fungsinya. Mereka nantinya akan berkomentar dan akhirnya menghapus kode tes ketika aplikasi siap digunakan.
• Pengembang juga dapat mengisolasi fungsi untuk mengujinya dengan lebih ketat. Ini adalah praktik pengujian unit yang lebih menyeluruh yang melibatkan salin dan tempel kode ke lingkungan pengujiannya sendiri daripada lingkungan alaminya. Mengisolasi kode membantu mengungkapkan ketergantungan yang tidak perlu antara kode yang sedang diuji dan unit atau ruang data lain dalam produk. Ketergantungan ini kemudian dapat dihilangkan.
• Seorang coder umumnya menggunakan Kerangka UnitTest untuk mengembangkan kasus uji otomatis. Menggunakan kerangka kerja otomatisasi, pengembang kode membuat kriteria ke dalam tes untuk memverifikasi kebenaran kode. Selama pelaksanaan kasus uji, kerangka kerja mencatat kasus uji. Banyak kerangka kerja juga akan secara otomatis menandai dan melaporkan, secara ringkas, kasus pengujian yang gagal ini. Tergantung pada tingkat keparahan kegagalan, kerangka kerja dapat menghentikan pengujian selanjutnya.
• Alur kerja Unit Testing adalah 1) Buat Kasus Uji 2) Review / Pengerjaan Ulang 3) Baseline 4) Jalankan Uji Kasus.

Teknik Pengujian Unit

Teknik cakupan kode yang digunakan dalam pengujian terpadu tercantum di bawah ini:

• Cakupan Pernyataan
• Cakupan Keputusan
• Cakupan Cabang
• Cakupan Kondisi
• Cakupan Mesin Finite State

Contoh Pengujian Unit: Objek Mock

Pengujian unit bergantung pada objek tiruan yang dibuat untuk menguji bagian kode yang belum menjadi bagian dari aplikasi lengkap. Benda-benda tiruan mengisi bagian-bagian yang hilang dari program.

Misalnya, Anda mungkin memiliki fungsi yang memerlukan variabel atau objek yang belum dibuat. Dalam pengujian unit, itu akan diperhitungkan dalam bentuk objek tiruan yang dibuat semata-mata untuk tujuan pengujian unit yang dilakukan pada bagian kode tersebut.

Alat Uji Unit

Ada beberapa alat otomatis yang tersedia untuk membantu pengujian unit. Kami akan memberikan beberapa contoh di bawah ini:

1. Junit : Junit adalah alat pengujian gratis yang digunakan untuk bahasa pemrograman Java. Ini memberikan pernyataan untuk mengidentifikasi metode pengujian. Alat ini menguji data terlebih dahulu dan kemudian disisipkan dalam potongan kode.
2. NUnit : NUnit banyak digunakan kerangka kerja unit-testing digunakan untuk semua bahasa .net. Ini adalah alat open source yang memungkinkan penulisan skrip secara manual. Ini mendukung tes berbasis data yang dapat berjalan secara paralel.
3. JMockit : JMockit adalah alat pengujian Unit open source. Ini adalah alat cakupan kode dengan metrik garis dan jalur. Ini memungkinkan mengejek API dengan sintaks perekaman dan verifikasi. Alat ini menawarkan Cakupan garis, Cakupan Jalur, dan Cakupan Data.
4. EMMA : EMMA adalah toolkit open-source untuk menganalisis dan melaporkan kode yang ditulis dalam bahasa Jawa. Emma mendukung jenis cakupan seperti metode, garis, blok dasar. Ini berbasis Java sehingga tanpa dependensi pustaka eksternal dan dapat mengakses kode sumber.
5. PHPUnit : PHPUnit adalah alat pengujian unit untuk programmer PHP. Dibutuhkan bagian kecil dari kode yang disebut unit dan menguji masing-masing secara terpisah. Alat ini juga memungkinkan pengembang untuk menggunakan metode penegasan yang telah ditentukan sebelumnya untuk menyatakan bahwa suatu sistem berperilaku dengan cara tertentu. 

Itu hanya beberapa alat pengujian unit yang tersedia. Ada banyak lagi, terutama untuk bahasa C dan Java, tetapi Anda yakin untuk menemukan alat pengujian unit untuk kebutuhan pemrograman Anda terlepas dari bahasa yang Anda gunakan.

Test Driven Development (TDD) & Unit Testing

Pengujian unit dalam TDD melibatkan penggunaan kerangka pengujian yang luas. Kerangka uji unit digunakan untuk membuat tes unit otomatis. Kerangka kerja pengujian unit tidak unik untuk TDD, tetapi mereka penting untuk itu. Di bawah ini kita melihat beberapa hal yang dibawa TDD ke dunia pengujian unit:

• Tes ditulis sebelum kode
• Bergantung pada kerangka pengujian
• Semua kelas dalam aplikasi diuji
• Integrasi yang cepat dan mudah dimungkinkan

Mitos Pengujian Unit

Mitos: Itu membutuhkan waktu, dan saya selalu dijadwal ulang.
Kode saya solid! Saya tidak perlu tes unit.

Mitos pada dasarnya adalah asumsi yang salah. Asumsi-asumsi ini menyebabkan siklus setan sebagai berikut –

Kebenarannya adalah pengujian Unit meningkatkan kecepatan pengembangan.

Pemrogram berpikir bahwa Pengujian Integrasi akan menangkap semua kesalahan dan tidak menjalankan pengujian unit. Setelah unit terintegrasi, kesalahan yang sangat sederhana yang dapat dengan mudah ditemukan dan diperbaiki dalam unit yang diuji membutuhkan waktu yang sangat lama untuk dilacak dan diperbaiki.

Keuntungan Pengujian Unit

• Pengembang yang ingin mempelajari fungsionalitas apa yang disediakan oleh unit dan bagaimana menggunakannya dapat melihat tes unit untuk mendapatkan pemahaman dasar tentang API unit.
• Unit testing memungkinkan programmer untuk memperbaiki kode di kemudian hari, dan memastikan modul masih bekerja dengan benar (yaitu pengujian Regresi). Prosedurnya adalah menulis kasus uji untuk semua fungsi dan metode sehingga setiap kali perubahan menyebabkan kesalahan, ia dapat dengan cepat diidentifikasi dan diperbaiki.
• Karena sifat modular dari pengujian unit, kami dapat menguji bagian-bagian proyek tanpa menunggu yang lain diselesaikan.

Kerugian Pengujian Unit

• Pengujian unit tidak dapat diharapkan untuk menangkap setiap kesalahan dalam suatu program. Tidak mungkin untuk mengevaluasi semua jalur eksekusi bahkan dalam program yang paling sepele
• Pengujian unit pada dasarnya berfokus pada unit kode. Oleh karena itu tidak dapat menangkap kesalahan integrasi atau kesalahan tingkat sistem yang luas.

Dianjurkan pengujian unit digunakan bersamaan dengan aktivitas pengujian lainnya.

Unit Menguji Praktik Terbaik

• Kasus Unit Test harus independen. Dalam hal ada peningkatan atau perubahan dalam persyaratan, kasus uji unit tidak boleh terpengaruh.
• Uji hanya satu kode pada satu waktu.
• Ikuti konvensi penamaan yang jelas dan konsisten untuk pengujian unit Anda
• Dalam hal terjadi perubahan kode dalam modul apa pun, pastikan ada Unit Uji Kasus yang sesuai untuk modul tersebut, dan modul tersebut lulus tes sebelum mengubah implementasi
• Bug yang diidentifikasi selama pengujian unit harus diperbaiki sebelum melanjutkan ke fase berikutnya dalam SDLC
• Gunakan pendekatan “test as your code”. Semakin banyak kode yang Anda tulis tanpa pengujian, semakin banyak jalur yang harus Anda periksa untuk kesalahan.

Ringkasan

• PENGUJIAN UNIT didefinisikan sebagai jenis pengujian perangkat lunak di mana masing-masing unit atau komponen perangkat lunak diuji.
• Seperti yang Anda lihat, mungkin ada banyak yang terlibat dalam pengujian unit. Ini bisa rumit atau agak sederhana tergantung pada aplikasi yang sedang diuji dan strategi pengujian, alat dan filosofi yang digunakan. Pengujian unit selalu diperlukan pada tingkat tertentu. Itu suatu kepastian.

Apa itu Pengujian Manual?

Apa itu Pengujian Manual?

Pengujian manual adalah pengujian perangkat lunak tempat pengujian dilakukan secara manual oleh QA Analyst. Ini dilakukan untuk menemukan bug dalam perangkat lunak yang sedang dikembangkan.

Dalam pengujian Manual, tester memeriksa semua fitur penting dari aplikasi atau perangkat lunak yang diberikan. Dalam proses ini, penguji perangkat lunak mengeksekusi kasus uji dan menghasilkan laporan pengujian tanpa bantuan alat pengujian perangkat lunak otomasi.

Ini adalah metode klasik dari semua jenis pengujian dan membantu menemukan bug dalam sistem perangkat lunak. Biasanya dilakukan oleh penguji yang berpengalaman untuk menyelesaikan proses pengujian perangkat lunak.

Apa itu Pengujian Otomasi?

Dalam Pengujian Perangkat Lunak Otomatis, penguji menulis kode / skrip pengujian untuk mengotomatiskan pelaksanaan pengujian. Penguji menggunakan alat otomatisasi yang sesuai untuk mengembangkan skrip pengujian dan memvalidasi perangkat lunak. Tujuannya adalah untuk menyelesaikan pengujian dalam waktu yang lebih singkat.

Pengujian otomatis sepenuhnya bergantung pada tes pra-skrip yang berjalan secara otomatis untuk membandingkan hasil aktual dengan hasil yang diharapkan. Ini membantu penguji untuk menentukan apakah suatu aplikasi berkinerja seperti yang diharapkan.

Pengujian otomatis memungkinkan Anda untuk melakukan tugas yang berulang dan uji regresi tanpa intervensi dari tester manual. Meskipun semua proses dilakukan secara otomatis, otomatisasi memerlukan upaya manual untuk membuat skrip pengujian awal.

Perbedaan Antara Pengujian Manual dan Pengujian Otomasi

Parameter	Pengujian Otomasi	Pengujian Manual
Definisi	Pengujian Otomasi menggunakan alat otomasi untuk menjalankan kasus pengujian.	Dalam pengujian manual, uji kasus dijalankan oleh penguji manusia dan perangkat lunak.
Waktu memproses	Pengujian otomatis jauh lebih cepat daripada pendekatan manual.	Pengujian manual memakan waktu dan memakan sumber daya manusia.
Pengujian Eksplorasi	Otomasi tidak memungkinkan pengujian acak	Pengujian eksplorasi dimungkinkan dalam Pengujian Manual
Investasi awal	Investasi awal dalam pengujian otomatis lebih tinggi. Padahal ROI lebih baik dalam jangka panjang.	Investasi awal dalam pengujian Manual relatif lebih rendah. ROI lebih rendah dibandingkan dengan pengujian Otomasi dalam jangka panjang.
Keandalan	Pengujian otomatis adalah metode yang andal, karena dilakukan oleh alat dan skrip. Tidak ada Kelelahan pengujian.	Pengujian manual tidak seakurat karena kemungkinan kesalahan manusia.
Perubahan UI	Untuk perubahan sepele pada UI AUT, Script Pengujian Otomatis perlu dimodifikasi agar berfungsi seperti yang diharapkan	Perubahan kecil seperti perubahan id, kelas, dll. Dari sebuah tombol tidak akan menghalangi eksekusi tester manual.
Investasi	Investasi diperlukan untuk alat pengujian serta insinyur otomasi	Investasi diperlukan untuk sumber daya manusia.
Hemat biaya	Tidak hemat biaya untuk regresi volume rendah	Tidak hemat biaya untuk regresi volume tinggi.
Visibilitas Laporan Uji	Dengan pengujian otomatisasi, semua pemangku kepentingan dapat masuk ke sistem otomatisasi dan memeriksa hasil pelaksanaan pengujian	Tes Manual biasanya direkam dalam Excel atau Word, dan hasil tes tidak tersedia / siap.
Pengamatan manusia	Pengujian otomatis tidak melibatkan pertimbangan manusia. Jadi itu tidak pernah bisa memberikan jaminan keramahan pengguna dan pengalaman pelanggan yang positif.	Metode pengujian manual memungkinkan pengamatan manusia, yang mungkin berguna untuk menawarkan sistem yang ramah pengguna.
Pengujian Kinerja	Pengujian Kinerja seperti Pengujian Beban, Pengujian Stres, Pengujian Spike, dll. Harus diuji oleh alat otomatisasi secara wajib.	Pengujian Kinerja tidak layak secara manual
Eksekusi Paralel	Pengujian ini dapat dieksekusi pada platform operasi yang berbeda secara paralel dan mengurangi waktu pelaksanaan pengujian.	Tes manual dapat dilakukan secara paralel tetapi perlu meningkatkan sumber daya manusia Anda yang mahal
Pengujian batch	Anda dapat Batch beberapa Script Uji untuk eksekusi setiap malam.	Tes manual tidak dapat dikelompokkan.
Pengetahuan pemrograman	Pengetahuan pemrograman adalah suatu keharusan dalam pengujian otomatisasi.	Tidak perlu pemrograman dalam Pengujian Manual.
Mempersiapkan	Tes otomasi memerlukan pengaturan pelaksanaan pengujian yang tidak terlalu rumit.	Kebutuhan pengujian manual memiliki pengaturan pelaksanaan pengujian yang lebih mudah
Keterikatan	Dilakukan dengan alat. Ini akurat dan tidak pernah bosan!	Eksekusi Tes Manual Berulang bisa membosankan dan rentan kesalahan.
Pendekatan ideal	Pengujian otomasi berguna ketika sering melakukan serangkaian kasus uji yang sama	Pengujian manual terbukti bermanfaat ketika test case hanya perlu dijalankan sekali atau dua kali.
Bangun Pengujian Verifikasi	Pengujian otomasi berguna untuk Build Verification Testing (BVT).	Menjalankan Pengujian Verifikasi Bangun (BVT) sangat sulit dan menghabiskan banyak waktu dalam pengujian manual.
Tenggat waktu	Tes Otomatis memiliki risiko nol untuk melewatkan tes yang telah ditentukan sebelumnya.	Pengujian Manual memiliki risiko lebih tinggi untuk melewatkan batas waktu pengujian yang telah ditentukan sebelumnya.
Kerangka	Pengujian otomasi menggunakan kerangka kerja seperti Drive Data, Kata Kunci, Hibrid untuk mempercepat proses otomasi.	Pengujian Manual tidak menggunakan kerangka kerja tetapi dapat menggunakan pedoman, daftar periksa, proses ketat untuk menyusun kasus uji tertentu.
Dokumentasi	Tes Otomatis bertindak sebagai dokumen yang memberikan nilai pelatihan terutama untuk kasus uji unit otomatis. Pengembang baru dapat melihat kasus uji unit dan memahami basis kode dengan cepat.	Kotak uji manual tidak memberikan nilai pelatihan
Desain Tes	Tes Unit Otomatis menegakkan / mendorong Desain Pengembangan Berbasis Tes.	Tes Unit Manual tidak mendorong desain ke dalam proses pengkodean
Devops	Tes Otomatis membantu dalam Pengujian Verifikasi Bangun dan merupakan bagian integral dari Siklus DevOps	Pengujian Manual mengalahkan prinsip build otomatis dari DevOps
Kapan Harus Digunakan?	Pengujian Otomatis cocok untuk Pengujian Regresi, Pengujian Kinerja, Pengujian Beban atau kasus uji fungsional yang sangat berulang.	Pengujian Manual cocok untuk Eksplorasi, Kegunaan, dan Pengujian Adhoc. Ini juga harus digunakan di mana AUT sering berubah.

Pro dan Kontra Pengujian Manual

Kelebihan Pengujian Manual:

• Dapatkan umpan balik visual yang cepat dan akurat
• Itu lebih murah karena Anda tidak perlu menghabiskan anggaran untuk alat dan proses otomasi
• Penilaian dan intuisi manusia selalu menguntungkan elemen manual
• Saat menguji perubahan kecil, tes otomatisasi akan membutuhkan pengkodean yang mungkin memakan waktu. Sementara Anda bisa menguji secara manual dengan cepat.

Kontra Pengujian Manual:

• Metode pengujian yang kurang andal karena dilakukan oleh manusia. Karena itu, selalu rentan terhadap kesalahan & kesalahan.
• Proses pengujian manual tidak dapat direkam, jadi tidak mungkin untuk menggunakan kembali tes manual.
• Dalam metode pengujian ini, tugas tertentu sulit dilakukan secara manual yang mungkin memerlukan waktu tambahan pada fase pengujian perangkat lunak.

Pro dan Kontra Pengujian Otomatis

Kelebihan pengujian otomatis:

• Pengujian otomatis membantu Anda menemukan lebih banyak bug dibandingkan dengan penguji manusia
• Karena sebagian besar bagian dari proses pengujian adalah otomatis, Anda dapat memiliki proses yang cepat dan efisien
• Proses otomasi dapat direkam. Ini memungkinkan Anda untuk menggunakan kembali dan menjalankan jenis operasi pengujian yang sama
• Pengujian otomatis dilakukan menggunakan alat perangkat lunak, sehingga bekerja tanpa melelahkan dan kelelahan tidak seperti manusia dalam pengujian manual
• Ini dapat dengan mudah meningkatkan produktivitas karena memberikan hasil pengujian yang cepat & akurat
• Pengujian otomatis mendukung berbagai aplikasi
• Cakupan pengujian dapat ditingkatkan karena alat pengujian otomatisasi tidak pernah lupa untuk memeriksa bahkan unit terkecil

Kontra Pengujian Otomatis:

• Tanpa elemen manusia, sulit untuk mendapatkan wawasan tentang aspek visual dari UI Anda seperti warna, font, ukuran, kontras atau ukuran tombol.
• Alat untuk menjalankan pengujian otomatisasi bisa mahal, yang dapat meningkatkan biaya proyek pengujian.
• Alat pengujian otomasi belum mudah. Setiap alat otomasi memiliki keterbatasan yang mengurangi ruang lingkup otomasi.
• Debugging skrip pengujian adalah masalah besar lainnya dalam pengujian otomatis. Perawatan uji biayanya mahal.

PERBEDAAN KUNCI

• Pengujian Manual dilakukan secara manual oleh analis QA (Manusia) sedangkan Pengujian Otomasi dilakukan dengan menggunakan skrip, kode, dan alat otomasi (komputer) oleh tester.
• Proses Pengujian Manual tidak akurat karena kemungkinan kesalahan manusia sedangkan proses Otomasi dapat diandalkan karena berbasis kode dan skrip.
• Pengujian Manual adalah proses yang memakan waktu sedangkan Pengujian Otomasi sangat cepat.
• Pengujian Manual dimungkinkan tanpa pengetahuan pemrograman sedangkan Pengujian Otomatisasi tidak mungkin tanpa pengetahuan pemrograman.
• Pengujian Manual memungkinkan Pengujian acak sedangkan Pengujian Otomasi tidak mengizinkan Pengujian acak