Tata Kelola Teknologi Informasi

Sumber gambar: dosen.perbanas.id

Teknologi informasi (TI) saat ini sudah menjadi kebutuhan yang sangat penting bagi hampir semua organisasi perusahaan baik pemerintahan maupun swasta. TI sebagai penunjang dalam meningkatkan efektifitas dan efisiensi proses kinerja. Untuk mencapai hal tersebut diperlukan suatu pengelolaan TI yang baik dan benar, sehingga keberadaan TI dirasakan termanfaatakan oleh organisasi.

Dengan tata kelola TI di dalam suatu organisasi perusahaan, semua aktifitas TI yang ada dapat berjalan secara sistematis, terkendali dan efektif. Bahkan pada menciptakan efisiensi dengan sendirinya mengurangi biaya operasional dan meningkatkan daya saing. Luaran dari tata kelola TI yang baik tersebut hanya dapat dicapai jika tata kelola tersebut dikembangkan dengan menggunakan IT Framework berstandar internasional, misalnya dengan mengimplementasikan COBIT, IT-IL Management, COSO, ISO IT Security dan sebagainya.

Maka dapat disimpulkan, bahwa tujuan dibangunnya tata kelola TI yang baik adalah menyelaraskan sumber daya TI yang sudah diinvestasikan dengan strategi organisasi dengan menggunakan kerangka kerja berstandar internasional.

Berikut beberapa materi perkulihan tata kelola TI  :

• RPS dan Kontrak perkuliahan
• Konsep Tata Kelola TI Download
• Cobit untuk Tata Kelola IT Download
• Governance Stakeholder Download
• Cobit Principles Download
• Governance System and Components Download  
• Focus Areas and Design Factor Cobit Download
• Goal Cascade Download
• EDM Download
• APO Download
• BAI Download
• DSS Download 
  
• MEA 
• Ujian Akhir Semester Link

Sumber referensi :

• Tata Kelola TI Download
• Konsep Dasar Tata Kelola TI Download
• COBIT-2019-Framework-Introduction-and-Methodology Download 
• Governance and Management Objectives Download
• Website 1
  
• Youtube
  

Read More →

Implementasi dan Maintance Sistem

Dalam proses akhir dari pengembangan sebuah sistem yaitu melakukan implementasi dan pemeliharaan. Berikut materi yang akan kita dalami dalam pertemuan implementasi dan maintance sistem Download 

Read More →

Pengujian Aplikasi Berorientasi Objek

Strategi pengujian perangkat lunak klasik dimulai dengan pengujian kecil dan bekerja keluar menuju pengujian besar. Dalam pengujian OO dimulai dengan pengujian unit kemudian berlanjut ke pengujian integrasi dan berakhir dengan validasi dan pengujian sistem. 

• Pengujian unit

Unit terkecil yang dapat diuji di dalam perangkat lunak OO adalah kelas. Pengendalian kelas dikendalikan oleh operasi-operasi yang terenkapsulasi dalam kelas dan perilaku state dari kelas tersebut

• Pengujian integrasi

Pengujian integrasi terhadap perangkat lunak OO menguji sekumpulan kelas yang diperlukan untuk memberikan respons terhadap sebuah event yang diberikan.

• Pengujian validasi

Validasi perangkat lunak OO berfokus pada aksi-aksi yang terlihat oleh pengguna dan keluaran-keluaran yang dikenali oleh pengguna sistem tersebut. Validasi menggunakan use case, untuk menyediakan skenario yang kemungkinan besar menemukan kesalahan dalam kebutuhan interaksi pengguna. Metode black box testing dapat juga digunakan untuk mengendalikan pengujian validasi.

Metode perancangan use case untuk perangkat lunak OO telah disarankan oleh Berrard (Ber93) :

- Setiap test case harus diidentifikasi secara unik dan secara eksplisit terkait dengan kelas yang diuji

- Tujuan pengujian harus dinyatakan

- Daftar-daftar langkah pengujian harus dikembangkan untuk setiap pengujian dan harus berisi : daftar keadaan, daftar massage, daftar eksepsi, daftar kondisi eksternal dan informasi tambahan.

Materi perkuliahan : Download

Referensi : Buku RPL Roger S.Pressman Edisi 7  Bab.19 Pengujian Aplikasi-aplikasi berorientasi objek E-Book

Read More →

Equivalence Partitioning Technique

Partisi ekivalensi adalah teknik pengujian perangkat lunak di mana data masukan dibagi menjadi partisi dengan nilai yang valid dan tidak valid, dan semua partisi harus menunjukkan perilaku yang sama. Jika suatu kondisi suatu partisi benar, maka kondisi partisi lain yang setara juga harus benar, dan jika kondisi suatu partisi salah, maka kondisi partisi lain yang setara juga harus salah. Prinsip partisi ekivalensi adalah, kasus uji harus dirancang untuk mencakup setiap partisi setidaknya satu kali. Setiap nilai dari setiap partisi yang sama harus menunjukkan perilaku yang sama seperti yang lain.

Dalam menggunakan teknik pressman, dua kondisi pertama diuji, tetapi jika kita menggunakan metode latihan, ketiga kondisi tersebut terpenuhi. Kita tidak perlu menggunakan pendekatan latihan untuk semua aplikasi. Suatu saat kita akan menggunakan metode pressman juga. Namun, jika penerapannya lebih presisi, maka kita akan menggunakan metode latihan.

Jika kita ingin menggunakan metode latihan, sebaiknya ikuti aspek-aspek berikut ini:

- Itu harus spesifik untuk produk

- Ini harus spesifik pada kasus tertentu

- Jumlah pembagian tergantung pada presisi (pengurangan 2% dan 3%)

Contoh Teknik Equivalence Partitioning  : Download

Sumber : https://www.javatpoint.com/equivalence-partitioning-technique-in-black-box-testing

Read More →

Boundary Value Analysis

Analisis nilai batas adalah salah satu teknik desain kasus yang banyak digunakan untuk pengujian black box. Ini digunakan untuk menguji nilai batas karena nilai masukan yang dekat dengan batas memiliki kemungkinan kesalahan yang lebih tinggi.

Setiap kali kita melakukan pengujian dengan analisis nilai batas, penguji berfokus pada, sambil memasukkan nilai batas, apakah perangkat lunak menghasilkan keluaran yang benar atau tidak.

Nilai batas adalah nilai yang memuat batas atas dan bawah suatu variabel. Asumsikan, usia adalah variabel dari fungsi apa pun, dan nilai minimumnya adalah 18 dan nilai maksimumnya adalah 30, 18 dan 30 akan dianggap sebagai nilai batas.

Asumsi dasar analisis nilai batas adalah, kasus uji yang dibuat menggunakan nilai batas kemungkinan besar akan menimbulkan kesalahan.

Ada 18 dan 30 yang merupakan nilai batas sehingga tester lebih memperhatikan nilai tersebut, namun bukan berarti nilai tengah seperti 19, 20, 21, 27, 29 diabaikan. Kasus uji dikembangkan untuk setiap nilai rentang.

Pengujian nilai batas dilakukan dengan membuat partisi valid dan invalid. Partisi yang tidak valid diuji karena pengujian keluaran dalam kondisi buruk juga penting.

Mari kita pahami melalui praktik:

Bayangkan, ada fungsi yang menerima angka antara 18 hingga 30, dimana 18 adalah nilai minimum dan 30 adalah nilai maksimum dari partisi yang valid, nilai lain dari partisi ini adalah 19, 20, 21, 22, 23, 24, 25 , 26, 27, 28 dan 29. Partisi yang tidak valid terdiri dari angka yang kurang dari 18 seperti 12, 14, 15, 16 dan 17, dan lebih dari 30 seperti 31, 32, 34, 36 dan 40. Penguji mengembangkan kasus uji untuk partisi yang valid dan tidak valid untuk menangkap perilaku sistem pada kondisi masukan yang berbeda.

Sistem perangkat lunak akan lulus pengujian jika menerima nomor yang valid dan memberikan keluaran yang diinginkan, jika tidak maka tidak berhasil. Dalam skenario lain, sistem perangkat lunak tidak boleh menerima nomor yang tidak valid, dan jika nomor yang dimasukkan tidak valid, maka sistem akan menampilkan pesan kesalahan.

Jika perangkat lunak yang sedang diuji, mengikuti semua pedoman dan spesifikasi pengujian, maka perangkat lunak tersebut dikirim ke tim rilis, sebaliknya ke tim pengembangan untuk memperbaiki cacatnya.

Sumber : https://www.javatpoint.com/boundary-value-analysis-in-black-box-testing

Read More →

Pengujian Black Box

Pengujian black box adalah teknik pengujian perangkat lunak yang menguji fungsionalitas perangkat lunak tanpa melihat struktur internal atau pengkodeannya. Sumber utama pengujian black box adalah spesifikasi persyaratan yang dinyatakan oleh pelanggan.

Dalam metode ini, penguji memilih suatu fungsi dan memberikan nilai masukan untuk memeriksa fungsionalitasnya, dan memeriksa apakah fungsi tersebut memberikan keluaran yang diharapkan atau tidak. Jika fungsi menghasilkan keluaran yang benar, maka fungsi tersebut lolos dalam pengujian, jika tidak maka gagal. Tim penguji melaporkan hasilnya kepada tim pengembangan dan kemudian menguji fungsi selanjutnya. Setelah selesai pengujian seluruh fungsi jika terdapat masalah yang parah, maka diberikan kembali kepada tim pengembang untuk diperbaiki.

Langkah-langkah umum pengujian kotak hitam

• Pengujian black box didasarkan pada spesifikasi persyaratan, sehingga diperiksa terlebih dahulu.
• Pada langkah kedua, penguji membuat skenario pengujian positif dan skenario pengujian negatif dengan memilih nilai masukan yang valid dan tidak valid untuk memeriksa apakah perangkat lunak memprosesnya dengan benar atau salah.
• Pada langkah ketiga, penguji mengembangkan berbagai kasus uji seperti tabel keputusan, uji semua pasangan, pembagian ekuivalen, estimasi kesalahan, grafik sebab-akibat, dll.
• Fase keempat mencakup pelaksanaan semua kasus uji.
• Pada langkah kelima, penguji membandingkan keluaran yang diharapkan dengan keluaran sebenarnya.
• Pada langkah keenam dan terakhir, jika ada cacat pada perangkat lunak, maka perangkat lunak tersebut diperbaiki dan diuji kembali.

Prosedur Pengujian

Prosedur pengujian pengujian black box adalah sejenis proses di mana penguji memiliki pengetahuan khusus tentang kerja perangkat lunak, dan mengembangkan kasus pengujian untuk memeriksa keakuratan fungsionalitas perangkat lunak.

Itu tidak memerlukan pengetahuan pemrograman perangkat lunak. Semua kasus uji dirancang dengan mempertimbangkan masukan dan keluaran suatu fungsi tertentu. Seorang penguji mengetahui keluaran pasti dari masukan tertentu, tetapi tidak mengetahui bagaimana hasil tersebut timbul. Ada berbagai teknik yang digunakan dalam pengujian black box untuk pengujian seperti teknik tabel keputusan, teknik analisis nilai batas, transisi keadaan, pengujian semua pasangan, teknik grafik sebab-akibat, teknik partisi ekuivalen, teknik tebakan kesalahan, teknik use case dan teknik cerita pengguna.

Uji kasus

Kasus uji dibuat dengan mempertimbangkan spesifikasi persyaratan. Kasus uji ini umumnya dibuat dari deskripsi kerja perangkat lunak termasuk persyaratan, parameter desain, dan spesifikasi lainnya. Untuk pengujian, perancang pengujian memilih skenario pengujian positif dengan mengambil nilai masukan yang valid dan skenario pengujian negatif dengan mengambil nilai masukan yang tidak valid untuk menentukan keluaran yang benar. Kasus uji terutama dirancang untuk pengujian fungsional tetapi juga dapat digunakan untuk pengujian non-fungsional. Kasus uji dirancang oleh tim pengujian, tidak ada keterlibatan tim pengembangan perangkat lunak.

Teknik yang Digunakan dalam Pengujian Black Box

Decision Table Technique

Decision Table Technique adalah pendekatan sistematis di mana berbagai kombinasi masukan dan perilaku sistem masing-masing ditangkap dalam bentuk tabel. Cocok untuk fungsi yang memiliki hubungan logis antara dua atau lebih dari dua masukan.

Boundary Value Technique

Boundary Value Technique digunakan untuk menguji nilai batas, nilai batas adalah nilai yang memuat batas atas dan batas bawah suatu variabel. Ini menguji, sambil memasukkan nilai batas apakah perangkat lunak menghasilkan keluaran yang benar atau tidak.

State Transition Technique

State Transition Technique digunakan untuk menangkap perilaku aplikasi perangkat lunak ketika nilai masukan berbeda diberikan ke fungsi yang sama. Hal ini berlaku untuk jenis aplikasi yang memberikan jumlah upaya tertentu untuk mengakses aplikasi tersebut.

All-pair Testing Technique

All-pair Testing Technique digunakan untuk menguji semua kemungkinan kombinasi nilai diskrit. Metode kombinasional ini digunakan untuk menguji aplikasi yang menggunakan input kotak centang, input tombol radio, kotak daftar, kotak teks, dll.

Cause-Effect Technique

Cause-Effect Technique menggarisbawahi hubungan antara hasil tertentu dan semua faktor yang mempengaruhi hasil. Teknik ini didasarkan pada kumpulan persyaratan.

Equivalence Partitioning Technique

Equivalence Partitioning Technique adalah teknik pengujian perangkat lunak di mana data masukan dibagi menjadi partisi dengan nilai yang valid dan tidak valid, dan semua partisi harus menunjukkan perilaku yang sama.

Error Guessing Technique

Error Guessing Technique adalah teknik yang tidak ada metode khusus untuk mengidentifikasi kesalahan. Hal ini didasarkan pada pengalaman analis pengujian, dimana penguji menggunakan pengalaman tersebut untuk menebak area masalah pada perangkat lunak.

Use Case Technique

Use Case Technique yang digunakan untuk mengidentifikasi kasus uji dari awal hingga akhir sistem sesuai penggunaan sistem. Dengan menggunakan teknik ini, tim penguji membuat skenario pengujian yang dapat menguji seluruh perangkat lunak berdasarkan fungsionalitas masing-masing fungsi dari awal hingga akhir.

Materi tambahan : Download

Sumber : https://www.javatpoint.com/black-box-testing

Read More →

Pengujian White Box

Pengujian whitebox biasa dikenal sebagai glassbox testing, structural testing, clear box testing, open box testing dan transparent box testing. Metode ini berfokus menguji pengkodean internal dan infrastruktur perangkat lunak, yang fokus pada pemeriksaan masukan yang telah ditentukan sebelumnya terhadap keluaran yang diharapkan dan diinginkan. Ini didasarkan pada cara kerja aplikasi dan berkisar pada pengujian struktur internal. Dalam pengujian jenis ini diperlukan keterampilan pemrograman untuk merancang kasus uji. Tujuan utama dari pengujian white box adalah untuk fokus pada aliran input dan output melalui perangkat lunak dan memperkuat keamanan perangkat lunak.

Kotak bening atau kotak putih atau nama kotak transparan menunjukkan kemampuan untuk melihat menembus kulit terluar perangkat lunak ke dalam cara kerja bagian dalamnya. Dalam hal ini, pengembang akan menguji setiap baris kode program. Pengembang melakukan pengujian White-box kemudian mengirimkan aplikasi atau perangkat lunak tersebut ke tim pengujian, dimana mereka akan melakukan pengujian black box dan memverifikasi aplikasi beserta persyaratannya dan mengidentifikasi bug dan mengirimkannya ke pengembang.

Pengujian white box berisi berbagai pengujian, yaitu sebagai berikut:

• Path testing
• Loop testing
• Condition testing
• Testing based on the memory perspective
• Test performance of the program

Langkah-langkah umum pengujian kotak putih:

• Rancang semua skenario pengujian, uji kasus, dan prioritaskan berdasarkan nomor prioritas tinggi.
• Langkah ini melibatkan studi kode pada saat runtime untuk memeriksa pemanfaatan sumber daya, area kode yang tidak diakses, waktu yang dibutuhkan oleh berbagai metode dan operasi, dan seterusnya.
• Pada langkah ini dilakukan pengujian subrutin internal. Subrutin internal seperti metode nonpublik, antarmuka mampu menangani semua jenis data dengan tepat atau tidak.
• Langkah ini berfokus pada pengujian pernyataan kontrol seperti loop dan pernyataan kondisional untuk memeriksa efisiensi dan keakuratan input data yang berbeda.
• Pada langkah terakhir pengujian white box mencakup pengujian keamanan untuk memeriksa semua kemungkinan celah keamanan dengan melihat bagaimana kode menangani keamanan.

Alasan pengujian kotak putih:

• Ini mengidentifikasi lubang keamanan internal.
• Untuk memeriksa cara input di dalam kode.
• Periksa fungsionalitas loop bersyarat.
• Untuk menguji fungsi, objek, dan pernyataan pada tingkat individu.

Keuntungan pengujian kotak putih:

• Pengujian kotak putih mengoptimalkan kode sehingga kesalahan tersembunyi dapat diidentifikasi.
• Kasus uji pengujian kotak putih dapat dengan mudah diotomatisasi.
• Pengujian ini lebih menyeluruh dibandingkan pendekatan pengujian lainnya karena mencakup semua jalur kode.
• Itu dapat dimulai pada fase SDLC bahkan tanpa GUI.

Kerugian dari pengujian kotak putih:

• Pengujian kotak putih terlalu memakan waktu jika menyangkut aplikasi pemrograman skala besar.
• Pengujian kotak putih jauh lebih mahal dan rumit.
• Hal ini dapat menyebabkan kesalahan produksi karena tidak dirinci oleh pengembang.
• Pengujian white box membutuhkan programmer profesional yang memiliki pengetahuan dan pemahaman mendalam tentang bahasa pemrograman dan implementasinya.

Sumber : https://www.javatpoint.com/software-testing-tutorial

Download materi pertemuan whitebox : Link

Read More →

Kapan bisa melakukan System Testing ?

Ada empat tingkat pengujian perangkat lunak: pengujian unit, pengujian integrasi, pengujian sistem dan pengujian penerimaan, semuanya digunakan untuk tujuan pengujian. Unit Testing digunakan untuk menguji suatu perangkat lunak; Integration Testing digunakan untuk menguji sekelompok unit perangkat lunak, System Testing digunakan untuk menguji keseluruhan sistem dan Acceptance Testing digunakan untuk menguji penerimaan kebutuhan bisnis. Disini kita membahas pengujian sistem yang merupakan level pengujian tingkat ketiga.

Pengujian Sistem mencakup pengujian sistem perangkat lunak yang terintegrasi penuh. Umumnya sistem komputer dibuat dengan integrasi perangkat lunak (perangkat lunak apa pun hanya merupakan satu elemen dari sistem komputer). Perangkat lunak dikembangkan dalam unit-unit dan kemudian dihubungkan dengan perangkat lunak dan perangkat keras lain untuk membuat sistem komputer yang lengkap. Dengan kata lain, sistem komputer terdiri dari sekelompok perangkat lunak untuk melakukan berbagai tugas, tetapi hanya perangkat lunak yang tidak dapat melakukan tugas tersebut; untuk itu perangkat lunak harus dihubungkan dengan perangkat keras yang kompatibel. Pengujian sistem adalah serangkaian jenis pengujian yang berbeda dengan tujuan untuk melatih dan menguji kerja penuh sistem komputer perangkat lunak terintegrasi terhadap persyaratan.

Untuk memeriksa aliran end-to-end suatu aplikasi dikenal sebagai pengujian sistem. Dalam hal ini, menelusuri semua modul yang diperlukan dari suatu aplikasi dan memeriksa apakah fitur akhir berfungsi dengan baik, dan menguji produk secara keseluruhan sistem. Ini adalah pengujian end-to-end yang lingkungan pengujiannya mirip dengan lingkungan produksi.

Ada dua metode yang banyak digunakan untuk pengujian perangkat lunak, satu adalah pengujian kotak putih yang menggunakan pengkodean internal untuk merancang kasus pengujian dan yang lainnya adalah pengujian kotak hitam yang menggunakan GUI atau perspektif pengguna untuk mengembangkan kasus pengujian.

Pengujian sistem termasuk dalam pengujian Black box karena mencakup pengujian kerja eksternal perangkat lunak. Pengujian mengikuti perspektif pengguna untuk mengidentifikasi cacat kecil. Pengujian Sistem mencakup langkah-langkah berikut :

• Verifikasi fungsi masukan aplikasi untuk menguji apakah menghasilkan keluaran yang diharapkan atau tidak.
• Pengujian perangkat lunak terintegrasi dengan menyertakan periferal eksternal untuk memeriksa interaksi berbagai komponen satu sama lain.
• Pengujian keseluruhan sistem untuk pengujian End to End.
• Pengujian perilaku aplikasi melalui pengalaman pengguna

Jenis System Testing

Pengujian sistem dibagi menjadi lebih dari 50 jenis, namun perusahaan pengujian perangkat lunak biasanya menggunakan beberapa di antaranya, seperti di bawah ini:

Regression Testing

Pengujian regresi dilakukan dalam pengujian sistem untuk mengonfirmasi dan mengidentifikasi apakah ada cacat pada sistem karena modifikasi pada bagian lain dari sistem. Hal ini memastikan, setiap perubahan yang dilakukan selama proses pengembangan tidak menimbulkan cacat baru dan juga memberikan jaminan; cacat lama tidak akan ada pada penambahan perangkat lunak baru seiring berjalannya waktu.

Load Testing

Pengujian beban dilakukan dalam pengujian sistem untuk memperjelas apakah sistem dapat bekerja di bawah beban waktu nyata atau tidak.

Functional Testing

Pengujian fungsional suatu sistem dilakukan untuk mengetahui apakah ada fungsi yang hilang dalam sistem. Penguji membuat daftar fungsi-fungsi penting yang harus ada dalam sistem dan dapat ditambahkan selama pengujian fungsional dan harus meningkatkan kualitas sistem.

Recovery Testing

Pengujian pemulihan suatu sistem dilakukan di bawah pengujian sistem untuk memastikan keandalan, kepercayaan, akuntabilitas sistem dan semuanya terletak pada keterampilan memulihkan sistem. 

Seharusnya dapat berhasil memulihkan dari semua kemungkinan kerusakan sistem. Dalam pengujian ini, akan menguji aplikasi untuk memeriksa seberapa baik aplikasi tersebut pulih dari kerusakan atau bencana.

Migration Testing

Pengujian migrasi dilakukan untuk memastikan bahwa jika sistem perlu dimodifikasi pada infrastruktur baru maka sistem tersebut harus dimodifikasi tanpa masalah apa pun.

Usability Testing

Tujuan dari pengujian ini untuk memastikan bahwa sistem sudah familiar dengan pengguna dan memenuhi tujuannya untuk apa yang seharusnya dilakukan.

Software and Hardware Testing

Pengujian sistem ini bertujuan untuk memeriksa kompatibilitas perangkat keras dan perangkat lunak. Konfigurasi perangkat keras harus kompatibel dengan perangkat lunak untuk menjalankannya tanpa masalah apa pun. Kompatibilitas memberikan fleksibilitas dengan menyediakan interaksi antara perangkat keras dan perangkat lunak.

Mengapa Pengujian Sistem Penting?

• Pengujian Sistem memberikan jaminan seratus persen atas kinerja sistem karena mencakup fungsi sistem secara menyeluruh.
• Ini mencakup pengujian arsitektur perangkat lunak Sistem dan kebutuhan bisnis.
• Ini membantu dalam mengurangi masalah langsung dan bug bahkan setelah produksi.
• Pengujian sistem menggunakan sistem yang ada dan sistem baru untuk memasukkan data yang sama pada keduanya dan kemudian membandingkan perbedaan fungsionalitas dari fungsi yang ditambahkan dan yang sudah ada sehingga, pengguna dapat memahami manfaat dari fungsi tambahan yang baru pada sistem.

Sumber : https://www.javatpoint.com/software-testing-tutorial

Read More →

Apa itu Integration Testing ?

    Pengujian integrasi adalah proses pengujian perangkat lunak tingkat kedua setelah pengujian unit. Dalam pengujian ini, unit atau komponen individu perangkat lunak diuji secara berkelompok. Fokus dari tingkat pengujian integrasi adalah untuk mengungkap defects pada saat interaksi antara komponen atau unit yang terintegrasi.

    Pengujian unit menggunakan modul untuk tujuan pengujian, dan modul-modul ini digabungkan dan diuji dalam pengujian integrasi. Perangkat Lunak ini dikembangkan dengan sejumlah modul perangkat lunak yang dikodekan oleh programmers yang berbeda. Tujuan pengujian integrasi adalah untuk memeriksa kebenaran komunikasi antar semua modul.

    Setelah semua komponen atau modul bekerja secara independen, maka kita perlu memeriksa aliran data antar modul dependen yang disebut pengujian integrasi. Mari kita lihat salah satu contoh aplikasi perbankan, seperti yang bisa kita lihat pada gambar jumlah transfer di bawah ini.

• Pertama, kita akan login sebagai pengguna P untuk mentransfer jumlah dan mengirim jumlah Rp. 200.000, pesan konfirmasi akan ditampilkan di layar sebagai jumlah yang berhasil ditransfer. Sekarang logout sebagai P dan login sebagai pengguna Q dan buka halaman jumlah saldo dan periksa saldo di akun itu = Saldo saat ini + Saldo Diterima. Oleh karena itu, uji integrasi berhasil.
• Kami juga memeriksa apakah jumlah saldo telah berkurang sebesar Rp. 200.000 di akun pengguna P.
• Klik transaksi, di P dan Q akan muncul pesan mengenai data dan waktu transfer jumlah.

Pedoman Pengujian Integrasi

• Kami melakukan pengujian integrasi hanya setelah pengujian fungsional selesai pada setiap modul aplikasi.
• Kami selalu melakukan pengujian integrasi dengan memilih modul demi modul sehingga diikuti urutan yang tepat, dan kami juga tidak melewatkan skenario integrasi apa pun.
• Pertama, tentukan strategi kasus uji yang dapat digunakan untuk menyiapkan kasus uji yang dapat dieksekusi berdasarkan data pengujian.
• Periksa struktur dan arsitektur aplikasi dan identifikasi modul penting untuk mengujinya terlebih dahulu dan juga identifikasi semua skenario yang mungkin.
• Rancang kasus uji untuk memverifikasi setiap antarmuka secara detail.
• Pilih data masukan untuk eksekusi kasus uji. Data masukan memainkan peran penting dalam pengujian.
• Jika kami menemukan bug, komunikasikan laporan bug tersebut kepada pengembang dan perbaiki cacat serta pengujian ulang.
• Lakukan pengujian integrasi positif dan negatif.

Pengujian positif menyiratkan bahwa jika total saldo adalah Rp. 15.000 dan kami mentransfer Rp. 1.500 dan memeriksa apakah jumlah transfer berfungsi dengan baik. Jika ya, maka ujiannya akan lulus.

Pengujian negatif artinya jika total saldo Rp. 15.000 dan kami mentransfer Rp. 20.000 dan memeriksa apakah transfer jumlah terjadi atau tidak, jika tidak terjadi maka tes lulus. Jika terjadi, berarti ada bug pada kode tersebut, dan kami akan mengirimkannya ke tim pengembangan untuk diperbaiki bug tersebut.

Aplikasi apa pun di dunia ini akan melakukan pengujian fungsional secara wajib, sedangkan pengujian integrasi akan dilakukan hanya jika modul-modulnya saling bergantung satu sama lain. Setiap skenario integrasi wajib memiliki sumber→ data→tujuan. Skenario apa pun dapat disebut sebagai skenario integrasi hanya jika data disimpan di tujuan. Pada aplikasi Gmail, Sumber bisa berupa Tulis, Data bisa berupa Email dan Tujuan bisa berupa Kotak Masuk.

Catatan :

• Ada beberapa fitur, kami mungkin hanya melakukan pengujian fungsional, dan ada beberapa fitur di mana kami melakukan pengujian fungsional dan integrasi berdasarkan persyaratan fitur tersebut.
• Memprioritaskan itu penting, dan kita harus melakukannya di semua tahapan, yang berarti kita akan membuka aplikasi dan memilih fitur mana yang perlu diuji terlebih dahulu. Lalu masuk ke fitur tersebut dan pilih komponen mana yang harus diuji terlebih dahulu. Buka komponen tersebut dan tentukan nilai apa yang akan dimasukkan terlebih dahulu.
• Dan jangan menerapkan aturan yang sama di mana pun karena logika pengujian bervariasi dari satu fitur ke fitur lainnya.
• Saat melakukan pengujian, kita harus menguji satu fitur secara keseluruhan dan kemudian melanjutkan ke fungsi lainnya.
• Di antara kedua fitur tersebut, kita harus melakukan hanya pengujian integrasi positif atau pengujian integrasi positif dan negatif, dan ini juga bergantung pada kebutuhan fitur.

Alasan Dibalik Pengujian Integrasi

Meskipun semua modul aplikasi perangkat lunak telah diuji pada unit pengujian, kesalahan masih tetap ada karena alasan berikut:

• Setiap modul dirancang oleh pengembang perangkat lunak individual yang logika pemrogramannya mungkin berbeda dari pengembang modul lain; pengujian integrasi menjadi penting untuk menentukan kerja modul perangkat lunak.
• Untuk memeriksa interaksi modul perangkat lunak dengan database apakah salah atau tidak. 
• Persyaratan dapat diubah atau ditingkatkan pada saat pengembangan modul. Persyaratan baru ini mungkin tidak diuji pada tingkat pengujian unit sehingga pengujian integrasi menjadi wajib.
• Ketidakcocokan antar modul perangkat lunak dapat menimbulkan kesalahan.
• Untuk menguji kompatibilitas perangkat keras dengan perangkat lunak.
• Jika penanganan pengecualian antar modul tidak memadai, hal ini dapat menimbulkan bug.

Jenis Pengujian Integrasi

Incremental Integration Testing

Dalam jenis pengujian ini, terdapat hubungan yang kuat antara modul dependen. Misalkan kita mengambil dua atau lebih modul dan memverifikasi bahwa aliran data di antara keduanya berfungsi dengan baik. Jika ya, tambahkan lebih banyak modul dan uji lagi. Contohnya, misalkan kita memiliki Aplikasi Flipkart, kita akan melakukan pengujian integrasi tambahan, dan alur aplikasinya akan seperti ini: Flipkart→ Login→ Home → Search→ Add cart→Payment → Logout

Top-Down Integration Testing

Strategi pengujian top-down berkaitan dengan proses di mana modul tingkat yang lebih tinggi diuji dengan modul tingkat yang lebih rendah hingga pengujian semua modul berhasil diselesaikan. Cacat desain utama dapat dideteksi dan diperbaiki sejak dini karena modul penting diuji terlebih dahulu. Dalam metode jenis ini, kita akan menambahkan modul secara bertahap atau satu per satu dan memeriksa aliran data dalam urutan yang sama.

Bottom-Up Integration Testing

Strategi pengujian dari bawah ke atas berkaitan dengan proses di mana modul tingkat yang lebih rendah diuji dengan modul tingkat yang lebih tinggi hingga pengujian semua modul berhasil diselesaikan. Modul penting tingkat atas akhirnya diuji, sehingga mungkin menyebabkan kerusakan. Atau kita dapat mengatakan bahwa kita akan menambahkan modul dari bawah ke atas dan memeriksa aliran data dalam urutan yang sama.

Non-Incremental Integration Testing

Kami akan menggunakan metode ini, ketika aliran data sangat kompleks dan ketika sulit untuk menemukan siapa yang merupakan Parent dan siapa yang merupakan Child. Dan dalam kasus seperti itu, kami akan membuat data di modul mana pun dan di semua modul lain yang ada dan memeriksa apakah datanya ada. Oleh karena itu, metode ini juga dikenal sebagai metode Big Bang.

Sumber : https://www.javatpoint.com/software-testing-tutorial

Read More →

Kenalan dengan Unit Testing

    Unit testing merupakan pengujian unit melibatkan pengujian setiap unit atau komponen individual dari aplikasi perangkat lunak. Ini adalah pengujian fungsional tingkat pertama. Tujuan di balik pengujian unit adalah untuk memvalidasi komponen unit dengan kinerjanya. Unit adalah satu bagian sistem perangkat lunak yang dapat diuji dan diuji selama tahap pengembangan perangkat lunak aplikasi.

    Tujuan pengujian unit adalah untuk menguji kebenaran kode yang diisolasi. Komponen unit adalah fungsi atau kode individual aplikasi. Pendekatan pengujian kotak putih digunakan untuk pengujian unit dan biasanya dilakukan oleh pengembang. Setiap kali aplikasi sudah siap dan diberikan kepada Test engineer, dia akan mulai memeriksa setiap komponen modul atau modul aplikasi secara mandiri atau satu per satu, dan proses ini dikenal sebagai Unit pengujian atau pengujian komponen.

Mengapa melakukan Unit Testing ?

    Dalam hierarki tingkat pengujian, pengujian unit adalah pengujian tingkat pertama yang dilakukan sebelum integrasi dan tingkat pengujian lainnya yang tersisa. Ia menggunakan modul untuk proses pengujian yang mengurangi ketergantungan menunggu kerangka pengujian Unit, stub, driver, dan objek tiruan digunakan untuk bantuan dalam pengujian unit.

Gambar : Tingkat pengujian

    Secara umum, perangkat lunak menjalani empat tingkat pengujian: Pengujian Unit, Pengujian Integrasi, Pengujian Sistem, dan Pengujian Penerimaan, namun terkadang karena konsumsi waktu, penguji perangkat lunak melakukan pengujian unit minimal namun melewatkan pengujian unit dapat menyebabkan cacat yang lebih tinggi selama Pengujian Integrasi, Sistem Pengujian, dan Pengujian Penerimaan atau bahkan selama Pengujian Beta yang berlangsung setelah selesainya aplikasi perangkat lunak.

Beberapa alasan penting, perlunya melakukan unit testing :

• Pengujian unit membantu penguji dan pengembang memahami dasar kode yang membuat mereka dapat mengubah kode penyebab kerusakan dengan cepat.
• Pengujian unit membantu dalam dokumentasi.
• Pengujian unit memperbaiki kerusakan pada tahap awal pengembangan, itulah sebabnya ada kemungkinan terjadinya lebih sedikit kerusakan pada tingkat pengujian mendatang.
• Ini membantu penggunaan kembali kode dengan memigrasikan kode dan menguji kasus.

Contoh dari Unit Testing

Berikut contoh untuk pemahaman yang lebih baik tentang konsep pengujian unit :

Gambar : Unit Testing

Untuk the amount transfer, persyaratannya sebagai berikut :

Saat melakukan pengujian unit, kita harus mengikuti beberapa aturan, yaitu sebagai berikut:

• Untuk memulai pengujian unit, setidaknya kita harus memiliki satu modul.

• Uji nilai positif

• Uji nilai negatif

• Tidak ada pengujian berlebihan

• Tidak diperlukan asumsi

Ketika merasa cakupan pengujian maksimal telah tercapai, maka akan menghentikan pengujian.
Sekarang, kita akan mulai melakukan pengujian unit pada berbagai komponen seperti :

• From account number(FAN)

• To account number(TAN)

• Amount

• Transfer

• Cancel

Gambar: Komponen pengujian

Untuk komponen FAN

Untuk komponen TAN

• Berikan nilai seperti yang kita lakukan pada komponen dari nomor akun (FAN).

Untuk komponen Amount

• Berikan nilai seperti yang kita lakukan pada komponen FAN dan TAN.

Untuk komponen Transfer

• Enter valid FAN value

• Enter valid TAN value

• Enter the correct value of Amount

• Click on the Transfer button→ amount transfer berhasil ( notifikasi)

Untuk komponen Cancel

• Enter the values of FAN, TAN, and amount.

• Click on the Cancel button → semua data yang tampil akan dibersihkan

Unit Testing Tool

Gambar: Unit Testing Tool

Teknik Unit Testing

    Pengujian unit menggunakan semua teknik pengujian kotak putih karena menggunakan kode aplikasi perangkat lunak, yang meliputi :

• Data flow Testing

• Control Flow Testing

• Branch Coverage Testing

• Statement Coverage Testing

• Decision Coverage Testing

Keuntungan Unit Testing

• Pengujian unit menggunakan pendekatan modul sehingga setiap bagian dapat diuji tanpa menunggu selesainya pengujian bagian lainnya.

• Tim pengembang berfokus pada fungsionalitas yang disediakan unit dan tampilan fungsionalitas dalam setelan pengujian unit untuk memahami API unit.

• Pengujian unit memungkinkan pengembang untuk memfaktorkan ulang kode setelah beberapa hari dan memastikan modul masih berfungsi tanpa cacat apa pun.

Kekurangan Unit Testing

• Itu tidak dapat mengidentifikasi integrasi atau kesalahan tingkat luas karena bekerja pada unit kode.

• Dalam pengujian unit, evaluasi seluruh jalur eksekusi tidak dimungkinkan, sehingga pengujian unit tidak mampu menangkap setiap kesalahan dalam suatu program.

Sumber : https://www.javatpoint.com/software-testing-tutorial

Read More →

Otomasi Testing VS Manual Testing Perangkat Lunak

Gambar (Sumber : Medium.com)

Otomasi Testing

Otomasi testing adalah salah satu teknik pengujian perangkat lunak dengan mengubah setiap kasus uji manual menjadi skrip pengujian dengan menggunakan alat pengujian otomasi, dan skrip atau bahasa pemrograman. Pengujian otomasi digunakan untuk meningkatkan efisiensi, efektivitas, dan cakupan dalam pengujian perangkat lunak.

Tester menggunakan alat pengujian otomasi untuk mengotomatisasi kasus uji desain manual tanpa campur tangan manusia. Dan alat pengujian ini dapat mengontrol pelaksanaan pengujian, mengakses data pengujian, dan membandingkan hasil aktual dengan hasil yang diharapkan.

Manual Testing

Pengujian manual adalah pengujian, dimana penguji dapat menguji aplikasi tanpa pengetahuan bahasa pemrograman apa pun. Dalam pengujian manual, teknisi pengujian menguji aplikasi seperti pengguna untuk menjadikannya bebas bug atau stabil.

Tester mencari kesalahan atau bug pada produk sebelum produk dirilis ke pasar, namun perangkat lunak yang dikirimkan masih memiliki cacat. Dan ada kemungkinan produk perangkat lunak akhir masih memiliki cacat atau tidak memenuhi kebutuhan pelanggan.

Berikut perbedaan yang sangat jelas dari beberapa aspek :

• Reability

Otomasi testing, sangat apat diandalkan karena proses pengujian aplikasi dengan bantuan alat dan skrip pengujian.

Manual testing, tidak dapat diandalkan karena ada kemungkinan kesalahan manusia, yang mungkin tidak menghasilkan aplikasi yang bebas bug.

• Reused

Otomasi testing, skrip ini dapat digunakan kembali di beberapa rilis.

Manual testing, al ini mungkin terjadi ketika test case hanya perlu dijalankan sekali atau dua kali.

• Penghematan waktu

Otomasi testing selalu lebih cepat daripada manual dan itulah mengapa proses pengujian otomatisasi menghemat waktu.

Manual testing memakan waktu karena penggunaan sumber daya manusia.

• Investasi

Otomasi testing saat menggunakan alat Otomasi, diperlukan investasi.

Manual testing, sumber daya manusia memerlukan investasi.

• Pengujian performa

Untuk menguji kinerja aplikasi dengan bantuan pengujian beban dan tegangan, insinyur pengujian otomasi perlu melakukan Pengujian Kinerja.

Dalam pengujian manual, pengujian kinerja tidak dimungkinkan.

• Pengetahuan pemrograman

Tanpa pemahaman bahasa pemrograman, kita tidak bisa menulis skrip tes.

Tidak perlu mengetahui bahasa pemrograman tetapi harus memiliki pengetahuan produk untuk menulis kasus uji.

• Kerangka kerja

Tester otomasi dapat menggunakan berbagai jenis kerangka kerja seperti berbasis data, Hibrida, berbasis modular, dan berbasis kata kunci untuk mempercepat proses otomasi.

Manual testing, tidak diperlukan kerangka kerja saat menggunakan pengujian manual.

• Kompatibilitas sistem operasi

Pengujian otomasi juga dapat dilakukan pada sistem berbeda dengan platform sistem operasi berbeda dan bahasa pemrograman berbeda.

Manual testing, kompatibilitas sistem operasi tidak dimungkinkan dalam pengujian manual karena diperlukan penguji yang berbeda untuk melakukan tugas tersebut

• Pengujian regresi

Setiap kali perubahan kode terjadi karena peningkatan rilis, teknisi uji otomasi akan melakukan pengujian regresi.

Manual testing, teknisi pengujian mengeksekusi kasus pengujian untuk pertama kalinya, ini mungkin berguna, namun ada kemungkinan ia tidak akan menangkap bug regresi karena persyaratan yang sering berubah.

Read More →

Mengorganisasi Proyek dalam Software Development

Struktur tim berguna untuk membahas pengaturan tim proyek individu dalam pengembangan perangkat lunak. Ada beberapa metode yang yang digunakan dalam mengatur tim proyek yang berbeda. Pada dasarnya ada tiga struktur tim formal: Chief programmer, Ego-less or democratic, dan Mixed team organizations. Tidak menutup kemungkinan ada beberapa variasi lain pada struktur yang mungkin terjadi. Dikarenakan masalah dengan kompleksitas dan ukuran yang berbeda-beda seringkali memerlukan struktur tim yang berbeda untuk solusi utamanya.

Chief programmer team

• Tim kepala pemrogram, memiliki hierarki. Terdiri dari seorang kepala pemrogram, yang memiliki pemrogram cadangan, pustakawan program, dan beberapa pemrogram.
• Kepala pemrogram sangat penting untuk semua keputusan teknis utama suatu proyek. Dia mengerjakan sebagian besar desain, dan dia memberikan pengkodean pada bagian desain yang berbeda kepada pemrogram.
• Pemrogram cadangan menggunakan kepala pemrogram untuk membuat keputusan teknis, dan mengambil alih kepala pemrogram jika kepala pemrogram jatuh sakit atau keluar.
• Pustakawan program sangat penting untuk memelihara dokumentasi dan pekerjaan terkait komunikasi lainnya.

Ego-less or democratic team

• Tim Ego-Less terdiri dari tim yang terdiri dari lebih sedikit pemrogram. Tujuan kelompok ditentukan melalui konsensus, dan masukan dari masing-masing anggota diambil untuk pengambilan keputusan penting.
• Kepemimpinan kelompok berputar di antara anggota kelompok. Karena sifatnya, tim tanpa ego secara konsisten dikenal sebagai tim demokratis.
• Struktur tersebut memungkinkan adanya masukan dari seluruh perwakilan, yang dapat menghasilkan keputusan yang lebih baik dalam berbagai permasalahan.
• Metode ini sangat cocok untuk proyek jenis penelitian jangka panjang yang tidak memiliki batasan waktu.

Controlled Decentralized Team

• Tim desentralisasi terkontrol mencoba menggabungkan kekuatan tim demokratis dan kepala pemrogram.
• Terdiri dari pemimpin proyek yang memiliki kelas programmer senior di bawahnya, sedangkan di bawah setiap programmer senior ada sekelompok programmer junior.
• Kelompok programmer senior dan programmer juniornya berperilaku seperti tim tanpa ego, tetapi komunikasi antar kelompok yang berbeda hanya terjadi melalui programmer senior dalam kelompok tersebut.
• Pemrogram senior juga berkomunikasi dengan pemimpin proyek.
• Tim seperti itu memiliki jalur komunikasi yang lebih sedikit dibandingkan tim demokratis, namun lebih banyak jalur dibandingkan dengan tim kepala pemrogram.
• Struktur ini berfungsi paling baik untuk proyek-proyek besar yang cukup mudah. Ini tidak cocok untuk proyek sederhana atau proyek jenis penelitian.

Read More →

Software Development

Software development merupakan istilah yang familiar bagi setiap developer atau programmer. Dalam mengembangkan perangkat lunak, kita membutuhkan software development dalam manajemen pengembanngan aplikasi yang dimulai dari perencanaan hingga peroses implementasi serta pemeliharaan aplikasi.

Jadi apakah itu software development ?

Secara istilah, software development adalah sebuah proses yang sistermatis dalam pengembangan perangkat lunak untuk menghasilkan perangkat lunak yang berkualitas. Dalam dunia developer perangkat lunak, istilah ini dikenal dengan System Developement Life Cycle (SDLC). SDLC merupakan siklus hidup pengembangan perangkat lunak. Tujuan dari SDLC agar perangkat lunak dapat direncanakan dengan baik, supaya perangkat lunak memenuhu target yang dibutuhkan sewaktu di rilis.

Tahapan SDLC itu apa saja ?

Tahap SDLC sendiri, bersifat fleksibel dan setiap perusahaan tentunya memiliki sistem pengembangan perangkat lunak yang berbeda – beda. Dikarenakan, untuk tahap software development sendiri disesuaikan dengan kebutuhan pengembangan produk atau tampilan aplikasi yang sesuai dengan permintaan klien. 

• Analisis, pada tahap untuk merencanakan rancangan pembuatan software atau aplikasi. Dimulai dari perencanaan alokasi sumber daya, biaya, estimasi waktu pengerjaan, kebutuhan tim, dan lain-lain. Pada tahap ini seorang Project Manager harus memikirkan matang-matang rencana pengerjaan proyek. Sehingga untuk kedepannya dapat dilakukan dengan baik. Dan yang terpenting, komunikasi dari tim developer dengan pihak manager dapat berjalan dengan selaras dan sinkron.
• Desain, pada tahap ini, pengembang akan merencanakan seluruh sistem dan merencanakan alur algoritma dengan baik. Proses desain disini tidak hanya dalam penentuan alur algoritma program. Tetapi, pembuatan desain awal tampilan akan diperhatikan agar saat masuk pada tim developer dapat mengimplementasikan dengan sempurna. Biasanya, tim UI / UX Designer dapat mengerjakan tugas ini untuk segera diserahkan nantinya kepada tim developer.
• Implementasi, setelah berhasil menentukan desain awal dari pengembangan aplikasi, selanjutnya akan diserahkan pada tim developer. Di tim software developer sendiri akan dibagi menjadi dua tim besar, front end dan back end. Setiap tim akan menjalankan tugas masing – masing. Dalam tahap ini masuk pada penulisan kode dengan menggunakan bahasa pemrograman tertentu. Semisal pada pembuatan website tim front end menggunakan bahasa pemrograman seperti HTML, CSS, dan JavaScript. Pada tim back end menggunakan PHP, Apache, SQL, Node.js, dll.
• Pengujian, pada tahap keempat setelah menyelesaikan proses pembuatan program, maka akan masuk pada tahap pengujian atau testing. Testing disini lebih pada pengujian program yang dibuat untuk mencari berbagai kesalahan seperti bug, error ataupun permasalahan lain yang dapat muncul dari software tersebut. Pada beberapa perusahaan besar ataupun startup, biasanya menempatkan tim khusus untuk menangani tahap pengujian. Quality Assurance (QA) merupakan posisi untuk menangani pengujian software. Pengujian dapat dilakukan dengan metode black box maupun white box. 
• Rilis, setelah menyelesaikan tahap testing, selanjutnya masuk pada perilisan produk. Proses deploy ini berarti software atau perangkat lunak telah berhasil dibuat dan siap untuk diserahkan pada klien. Dan untuk selebihnya, klien akan mencoba fungsionalitas dari aplikasi tersebut.
• Pemeliharaan, apabila saat proses deployment muncul sebuah problematika baru, maka klien dapat memberikan feedback kepada tim developer. Dan selanjutnya dapat dilakukan tahap maintenance atau perbaikan. Pada tahap ini, pihak pengembang dapat melakukan update versi atau penambahan fitur untuk mengatasi permasalahan dari klien tersebut.

Read More →

Kenalan sama si Andromo

 

Andromo: No-Code iOS and Android native apps development platform

Andromo adalah platform pembuatan aplikasi premium di mana seseorang dapat membuat aplikasi Android asli profesional tanpa menulis satu baris kode pun. Dengan langganan Andromo, Anda dapat membuat proyek dan membangun aplikasi Anda. Pembuatan aplikasi otomatis yang membawa proyek Anda dengan semua pengaturan dan fitur yang Anda masukkan. Menggunakan pengaturan dan fitur tersebut, Andromo mengonversinya menjadi Android.

Dalam pembuatan aplikasi, perlu diketahui bahwa di Andromo terdapat pilihan dalam membuat proyek app. Saat ini yang terbaru adalah versi 3 (V3). Oleh karena itu akan dipandu dengan membuat aplikasi dalam V3. Panduan membuat aplikasi pada kali ini hanyalah pengantar awal, karena selanjutnya Anda akan dituntut mengeluarkan dan mengekspresikan kreatifitas Anda, hingga Anda dapat membuat Aplikasi sesuai keinginan Anda.

Pengen tau lebih lanjut, langsung aja praktek nya di https://www.andromo.com/

Read More →

Tips membuat latar belakang tulisan

Dalam membuat tulisan ilmiah, ada beberapa hal yang harus diperhatikan, salah satunya adalah latar belakang. Latar belakang adalah bagian awal dari sebuah tulisan ilmiah. Latar belakang menuliskan tentang suatu kejadian, peristiwa atau keadaan yang melatarbelakangi mengapa  penelitian dilakukan. 

Ada beberapa langkah dalam membuat latar belakang tulisan, seperti proposal pengajuan dana, proposal penelitian hingga tugas akhir mahasiswa. 

• Bagian awal

Membuat gambaran umum tentang masalah yang diangkat. Bisa menggunakan teknik penulisan piramida terbalik untuk menciptakan gambaran umum terkait masalah global atau secara luas, hingga mengerucut dan akhirnya berfokus pada masalah inti, objek dan ruang lingkup yang hendak diteliti.

• Bagian tengah

Mengisikan fakta, fenomena, data-data dan pendapat ahli yang ada kaitannya dengan pentingnya masalah dan efek negatif jika masalah tersebut tidak segera diatasi. Pada bagian ini perlu didukung dengan teori dan penelitian terdahulu

• Bagian akhir

Memberikan tawaran berupa alternatif solusi, bisa teoritas hingga praktis. Dan dari sini bisa tarik kesimpulan untuk menentukan judul yang akan di angkat.

Dengan mengikuti sistematika penulisan latar belakang masalah, dapat menghasilkan latar belakang yang mengundang keinginan reviewer dan pembaca untuk mengetahui lebih lanjut permasalahan yang terjadi, proses penyelesaian masalah hingga hasil yang diharapkan.  

Read More →

Ternyata Mudah Membuat Akun Google Scholar

 Membuat Google Scholar

Google Scholar adalah alat pengindeks yang dikembangkan oleh google untuk menghimpun karya ilmiah dosen atau peneliti yang telah dipublikasikan secara online. Pada Google Scholar dapat dijadikan salah tolak ukur prestasi akademisi di bidang karya tulis ilmiah. Fasilitas ini, telah hadir sejak 2004 ini juga dapat dijadikan sebagai sumber rujukan atau sitasi dalam penulisan karya tulis ilmiah oleh para peneliti, dosen, maupun mahasiswa. 

Berikiut kami rincikan dengan mudah tutorial singkat untuk membuat akun di Google Scholar.

1. Sebelum membuat akun Google Scholar, Anda harus menyiapkan sebuah email yang terverifikasi dengan ektensi ac.id, or.id atau org. Untuk memiliki email ini Anda harus minta pada instansi tempat Anda bekerja untuk dibuatkan.
2. Buka laman Google Scholar di https://scholar.google.co.id/ dan login menggunakan email Anda. Akan Muncul
   
3. Klik ‘Profil Saya’ untuk melakukan pendaftaran, lalu lengkapilah Profil Anda dengan benar. Keterangan yang dibutuhkan antara lain nama lengkap, nama instansi, alamat email berkestensi Lembaga/instansi, bidang keilmuan, alamat website (jika memiliki). Setelah selesai, klik Lanjutkan.
   
   
   
4. Tambahkan Artikel. Google Scholar akan menyarankan beberapa artikel yang berkaitan dengan nama Anda. Silahkan dipilih dengan cara dicentang. Jika Anda belum mempunyai artikel, silahkan pilih sembarang artikel lalu klik tanda panah
5. Selanjutnya akan muncul option untuk setting terkait update artikel. Terdapat 2 opsi untuk pengaturan ini yang keduanya memiliki keunggulan dan kekurangan masing-masing jika diterapkan.  (a) Jika Anda memilih opsi UPDATE SECARA OTOMATIS, maka scholar akan menambahkan artikel secara otomatis ke profil Anda sehingga anda tidak perlu repot untuk menambahkan setiap publikasi anda ke profil scholar, namun dengan cara ini banyak kemungkinan artikel milik orang lain akan masuk dalam profil Anda karena adanya kesamaan metadata. Artinya anda harus memeriksa profil scholar secara berkala untuk memeriksa apakah ada artikel milik orang lain yang terdata diakun anda. Jika ada, maka anda dapat mengeluarkannya secara manual. (b) Jika anda memilih UPDATE MELALUI VERIFIKASI EMAIL, artinya google akan mengirim email untuk Anda verifikasi sebelum artikel dicantumkan ke profil scholar Anda. Cara ini lebih aman, namun anda pun harus memeriksa profil secara berkala untuk memeriksa apakah publikasi anda sudah masuk ke profil scholar anda atau belum. Umumnya dengan cara ini, anda perlu masuk ke akun untuk menambahkan artikel anda agar dapat tercantum di profil scholar. Intinya, apapun setingan yang anda terapkan, anda tetap diharuskan untuk memantau akun scholar anda secara berkala.
   

   

   
   
6. Centang ‘Jadikan Profil Saya untuk Umum‘ agar profil Google scholar Anda dapat dilihat dan disitasi oleh orang lain, lalu klik selesai
   

   

   
   
7. Langkah terakhir, silahkan hapus artikel milik orang lain yang Anda tambahkan tadi. Selanjutnya silahkan Anda perbanyak publikasi pada jurnal-jurnal terindeks secara online, lalu tambahkan secara manual untuk meningkatkan reputasi Anda di Google Scholar.

Demikian cara mudah untuk membuat akun di Google Scholar. Selanjutnya kita dapat melakukan editing seperlunya dengan menekan tombol yang sudah disediakan, seperti mengubah profil, menambah artikel, mengedit artikel dan menghapus artikel.

Terima kasih, semoga bermanfaat.

Read More →