Kriteria Manajer Proyek yang Baik

Manajer Proyek (Project Manager) adalah seseorang yang brtindak sebagai pimpinan dalam suatu proyek. PM ini sangat berperan penting dalam adanya suatu proyek, karena kegagalan dan keberhasilan dari proyek tersebut di tentukan oleh PM itu sendiri.

Untuk menjadi seorang PM yang baik diperlukan beberapa kriteria khusus agar proyek berhasil dengan baik. Kriteria tersebut dilihat dari berapa sisi diantaranya :

Karakter dari Kepribadinya
Karakteristik dari Kemampuan Terkait dengan Proyek yang Dikelola
Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin

1.  Karakter dari Kepribadiannya

Harus memahami dan menguasai semua hal baik secara teori maupun teknis terhadap proyek yang sedang di tangani.
Memiliki pengalaman dan keahlian yang berkaitan dengan proyek yang sedang dikelola.
Sebagai seorang yang mengambil keputusan, maka harus mampu bertindak secara adil dan bertanggung jawab.
Memiliki wibawa, mampu beradaptasi dan bergaul dengan bawahan sehingga tidak ada kesenjangan antara atasan dan bawahan.

2.  Karakteristik dari Kemampuan Terkait dengan Proyek yang Dikelola

Memiliki komitmen yang tinggi untuk meraih tujuan serta keberhasilan proyek.
Mampu menyelesaikan proyek sesuai dengan waktu dan anggaran yang diberikan.
Membuat dan melakukan rencana darurat untuk mengantisipasi hal-hal maupun masalah tak terduga.
Mampu membuat perencanaan dalam jangka panjang dan jangka pendek.
Memiliki kemauan untuk mendefinisikan ulang tujuan, tanggung jawab dan jadwal selama hal tersebut ditujukan untuk mengembalikan arah tujuan dari pelaksanaan proyek jika terjadi jadwal maupun anggaran yang meleset.

3.  Karakteristik Kemampuan Terkait dengan tim yang Dipimpin

Mampu bersosialisasi dengan bawahan atau anggota tim.
Mampu membangun kedisiplinan secara structural
Memiliki kemampuan dan keahlian berkomunikasi serta manjerial.
Menghormati para anggota tim kerjanya serta mendapat kepercayaan dan penghormatan dari mereka.
Memiliki kepercayaan yang tinggi kepada para profesional terlatih untuk menerima pekerjaan-pekerjaan yang didelegasikan darinya.
Berbagi sukses dengan seluruh anggota tim.
Mampu menempatkan orang yang tepat di posisi yang sesuai.
Memberikan apresiasi yang baik kepada para anggota tim yang bekerja dengan baik.


Sumber: http://www.setiabudi.name/archives/990
http://udifq.wordpress.com/kriteria-manajer-proyek-yang-baik/

COCOMO (Constructive Cost Model )

Constructive Cost Model (COCOMO) Merupakan algoritma estimasi biaya perangkat lunak model yang dikembangkan oleh Barry Boehm. Model ini menggunakan rumus regresi dasar, dengan parameter yang berasal dari data historis dan karakteristik proyek proyek saat ini.

Sejarah Singkat COCOMO
COCOMO pertama kali diterbitkan pada tahun 1981 Barry Boehm W. ’s Book ekonomi Software engineering sebagai model untuk memperkirakan usaha, biaya, dan jadwal untuk proyek-proyek perangkat lunak. Ini menarik pada studi dari 63 proyek di TRW Aerospace mana Barry Boehm adalah Direktur Riset dan Teknologi Perangkat Lunak pada tahun 1981. Penelitian ini memeriksa proyek-proyek ukuran mulai dari 2.000 sampai 100.000 baris kode, dan bahasa pemrograman mulai dari perakitan untuk PL / I. Proyek-proyek ini didasarkan pada model pengembangan perangkat lunak waterfall yang merupakan proses software umum pembangunan di 1981.
Referensi untuk model ini biasanya menyebutnya COCOMO 81. Pada tahun 1997 COCOMO II telah dikembangkan dan akhirnya diterbitkan pada tahun 2000 dalam buku Estimasi Biaya COCOMO II Software dengan COCOMO II. adalah penerus dari COCOMO 81 dan lebih cocok untuk mengestimasi proyek pengembangan perangkat lunak modern. Hal ini memberikan lebih banyak dukungan untuk proses pengembangan perangkat lunak modern, dan basis data proyek diperbarui. Kebutuhan model baru datang sebagai perangkat lunak teknologi pengembangan pindah dari batch processing mainframe dan malam untuk pengembangan desktop, usabilitas kode dan penggunaan komponen software off-the-rak. Artikel ini merujuk pada COCOMO 81.

Pengertian COCOMO
COCOMO terdiri dari tiga bentuk hirarki semakin rinci dan akurat. Tingkat pertama, Basic COCOMO adalah baik untuk cepat, order awal, kasar estimasi besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya faktor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers). Intermediate COCOMO mengambil Driver Biaya ini diperhitungkan dan Rincian tambahan COCOMO account untuk pengaruh fase proyek individu.

Model Jenis COCOMO Ada tiga model cocomo, diantaranya ialah:
1. Dasar Cocomo
Dengan menggunakan estimasi parameter persamaan (dibedakan menurut tipe sistem yang berbeda) upaya pengembangan dan pembangunan durasi dihitung berdasarkan perkiraan DSI.

Dengan rincian untuk fase ini diwujudkan dalam persentase. Dalam hubungan ini dibedakan menurut tipe sistem (organik-batch, sebagian bersambung-on-line, embedded-real-time) dan ukuran proyek (kecil, menengah, sedang, besar, sangat besar).
Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:

* Proyek organik (organic mode) Adalah proyek dengan ukuran relatif kecil, dengan anggota tim yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif fleksibel.
* Proyek sedang (semi-detached mode)Merupakan proyek yang memiliki ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang berbeda
* Proyek terintegrasi (embedded mode)Proyek yang dibangun dengan spesifikasi dan operasi yang ketat

Model COCOMO dasar ditunjukkan dalam persamaan 1, 2, dan 3 berikut ini:

keterangan

:

* E : besarnya usaha (orang-bulan)
* D : lama waktu pengerjaan (bulan)
* KLOC : estimasi jumlah baris kode (ribuan)
* P : jumlah orang yang diperlukan.

2. Intermediate Cocomo
Persamaan estimasi sekarang mempertimbangkan (terlepas dari DSI) 15 pengaruh faktor-faktor; ini adalah atribut produk (seperti kehandalan perangkat lunak, ukuran database, kompleksitas), komputer atribut-atribut (seperti pembatasan waktu komputasi, pembatasan memori utama), personil atribut ( seperti aplikasi pemrograman dan pengalaman, pengetahuan tentang bahasa pemrograman), dan proyek atribut (seperti lingkungan pengembangan perangkat lunak, tekanan waktu pengembangan). Tingkat pengaruh yang dapat diklasifikasikan sebagai sangat rendah, rendah, normal, tinggi, sangat tinggi, ekstra tinggi; para pengganda dapat dibaca dari tabel yang tersedia.

3. Detil Cocomo
Dalam hal ini adalah rincian untuk fase tidak diwujudkan dalam persentase, tetapi dengan cara faktor-faktor pengaruh dialokasikan untuk fase. Pada saat yang sama, maka dibedakan menurut tiga tingkatan hirarki produk (modul, subsistem, sistem), produk yang berhubungan dengan faktor-faktor pengaruh sekarang dipertimbangkan dalam persamaan estimasi yang sesuai. Selain itu detail cocomo dapat menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dll) dari proses rekayasa PL

Sumber : http://wartawarga.gunadarma.ac.id/2011/04/cocomo/

Open Source

Kelebihan dan Kekurangan Open Source

Open Source adalah program yang lisensinya memberi kebebasan kepada pengguna menjalankan program untuk apa saja, mempelajari dan memodifikasi program, dan mendistribusikan penggandaan program asli atau yang sudah dimodifikasi tanpa harus membayar royalti kepada pengembang sebelumnya. Free/Open Source Software (FOSS) atau perangkat lunak bebas dan Open Source (PLBOS) telah menjadi sebuah fenomena internasional. Dalam beberapa tahun terakhir, FOSS mengalami perubahan besar dari sebuah kata yang relatif tidak dikenal menjadi sebuah kata popular terbaru.

Fitur-fitur utama dari karakteristik Open Source adalah kebebasan user untuk:

1. Menggunakan software sesuai keinginannya.
2. Memiliki software yang tersedia sesuai kebutuhan.
3. Mendistribusikan software kepada user lainnya.

Isu-isu keamanan yang dihadapi sistem Open Source, mencakup beberapa filosofi keamanan umum dan bagaimana membuat lebih aman sistem tersebut dari para penyusup. Beberapa pengguna komputer yang merupakan anggota dari komunitas pengguna Open Source Software (OSS) dan free software berpendapat bahwa kode program mereka lebih aman karena kelemahan kode program mereka lebih mudah ditemukan dan diperbaiki oleh pemakai program tersebut. Sementara itu, komunitas hak-hak kepemilikan berpendapat bahwa pembukaan akses ke kode program pada OSS akan memudahkan bagi beberapa kelompok tertentu untuk menyerang program tersebut.

Kebebasan yang tak terbatas bagi tiap orang untuk mengakses kode program merupakan pedang bermata dua bagi software itu sendiri. Hal ini disebabkan karena kebebasan ini memberikan informasi tentang kelemahan software. Kemudian, yang terjadi adalah eksploitasi kelemahannya. Para hacker akan menggunakan kelemahan ini untuk melakukan hal-hal yang dapat merugikan pengguna software tersebut. Akibatnya akan lebih buruk jika software tersebut merupakan software yang vital bagi pengguna karena akan memungkinkan terjadinya penipuan, pencurian identitas, pencurian informasi, dan sebagainya.

Meskipun tidak ada sistem operasi atau platform yang aman secara sempurna, faktor – faktor seperti metoda pengembangan, arsitektur program, dan pasar target dapat berpengaruh besar terhadap keamanan, dan konsekuensinya dapat berakibat lebih mudah ditembus atau sebaliknya sulit ditembus.

Apa manfaat yang kita dapatkan dengan menggunakan Open Source? Ada banyak manfaat positif yang bisa kita peroleh dengan menggunakan Open Source, diantaranya :

• Kreativitas : Dengan Open Source kita bisa mempelajari cara kerja suatu perangkat lunak, memodifikasinya, bahkan membuat produk baru dari sumber yang ada.
• Kemandirian : Kita tidak perlu lagi tergantung pada suatu produk tertentu, bahkan dengan Open Source kita bisa membuat produk yang sekelas dengan perusahaan berskala raksasa seperti Microsoft.
• Penghematan :
• Legalitas

1. Hemat Waktu : Berapa banyak waktu yang kita sia-siakan untuk berurusan dengan virus komputer di sistem closed source (baca : Windows) ? Dengan menggunakan sistem operasi Open Source seperti 3D OS kita tidak perlu membuang waktu lagi berurusan dengan virus komputer.
2. Hemat Biaya : Berapa banyak biaya yang perlu kita keluarkan untuk pembelian suatu produk proprietary seperti Windows, Photoshop, MS Office dan lain-lainnya ?
3. Hemat Devisa : Berapa banyak devisa negara yang harus lari keluar negeri jika kita terus menggunakan produk proprietary ?

1. Mengurangi Tingkat Pembajakan : Open Source memungkinkan kita untuk tidak lagi menggunakan milik orang lain secara tidak sah atau dengan kata lain kita tidak perlu lagi menjadi pencuri. Selain mengurangi tingkat pembajakan, secara otomatis dosa-dosa kita juga ikut berkurang.
2. Meningkatkan Citra Negara : Tahukah Anda bahwa pembajakan menjadikan citra negara menurun ? Dan ini secara tidak langsung membawa akibat buruk pada hubungan dagang dengan luar negeri. Dan repotnya, di tahun 2009 ini Indonesia kembali masuk dalam daftar Priority Watch List.

Selain membawa manfaat, tentu saja Open Source juga mempunyai kekurangan, diantaranya :

• Kurangnya dukungan vendor : Harus diakui, masih cukup banyak vendor – baik Hardware, Software, ataupun Game – yang belum memberikan dukungan penuh padaOpen Source. Dan hal ini tentu saja cukup menghambat perkembangan Open Source.
• Kurangnya dukungan support : Karena belum cukup memasyarakat, maka dukungan support juga masih cukup sulit untuk ditemukan. Support untuk Open Source selama ini masih banyak bergantung pada Internet (baca : Google). Sehingga cukup menyulitkan mereka yang tidak mempunyai akses penuh pada Internet.
• Kurangnya dukungan bisnis : Pandangan bahwa Open Source adalah gratis dan tidak bisa membaa manfaat bisnis sangat menghambat para pebisnis yang akan terjun di Open Source. Kurangnya dukungan dari pebisnis ini membuat Open Source tidak bisa mempromosikan dirinya secara baik dan ini secara tidak langsung membuat pengenalan Open Source menjadi lebih lambat.
• Kurangnya promosi : Masih banyak orang yang beranggapan Open Source susah untuk dipergunakan, padahal perkembangan Open Source belakangan ini sudah cukup pesat dan bahkan dalam beberapa hal terkadang mampu menggungguli produk closed source. Kesalahpahaman ini bisa terjadi karena kurangnya promosi akan Open Source.

Sumber :

[1] http://linux.blog.gunadarma.ac.id/2012/12/27/1997/

[2] http://eziekim.wordpress.com/2012/04/01/alasan-menggunakan-software-open-source-kelebihan-dan-kekurangannya/

White Box Testing & Black Box Testing

Pengertian White Box Testing & Black Box Testing

NAMA   : SYLVAN JIWO PRAKOSO

KELAS  : 4KA20

NPM      : 16110809

DOSEN  : KUNTO BAYU A, ST

WHITE BOX TESTING

- Pengertian White Box Testing
White Box Testing merupakan cara pengujian dengan melihat ke dalam modul untuk meneliti kode-kode program yang ada, dan menganalisis apakah ada kesalahan atau tidak. Jika ada modul yang menghasilkan output yang tidak sesuai dengan proses bisnis yang dilakukan, maka baris-baris program, variabel, dan parameter yang terlibat pada unit tersebut akan dicek satu persatu dan diperbaiki, kemudian di-compile ulang.

- Dengan menggunakan white box akan didapatkan kasus uji yang :
• Menguji semua keputusan logikal
• Menguji seluruh Loop yang sesuai dengan batasannya
• Menguji seluruh struktur data internal yang menjamin validitas

- Kelebihan White Box Testing
• Kesalahan Logika
Digunakan pada sintaks ‘if’ dan pengulangan. Dimana White Box Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan mendeteksi kapan proses pengulangan akan berhenti.

• Ketidaksesuaian asumsi
Menampilkan asumsi yang tidak sesuai dengan kenyataan, untuk di analisa dan diperbaiki.

• Kesalahan ketik
Mendeteksi bahasa pemrograman yang bersifat case sensitive.

- Kelemahan White Box Testing
Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk melakukannya.

Pengujian White Box

Pengujian white box adalah pengujian yang didasarkan pada pengecekan terhadap detail perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.

Penggunaan metode pengujian white box dilakukan untuk :

• Memberikan jaminan bahwa semua jalur independen suatu modul digunakan minimal satu kali
• Menggunakan semua keputusan logis untuk semua kondisi true atau false
• Mengeksekusi semua perulangan pada batasan nilai dan operasional pada setiap kondisi.
• Menggunakan struktur data internal untuk menjamin validitas jalur keputusan.

Persyaratan dalam menjalankan strategi White Box Testing

• Mendefinisikan semua alur logika
• Membangun kasus untuk digunakan dalam pengujian
• Mengevaluasi semua hasil pengujian
• Melakukan pengujian secara menyeluruh

A) Notasi Diagram Alir (Path Graph Notation)

Notasi yang digunakan untuk menggambarkan jalur eksekusi adalah notasi diagram alir (atau grafik program), yang menggunakan notasi lingkaran (simpul atau node) dan anak panah (link atau edge). Notasi ini menggambarkan aliran control logika yang digunakan dalam suatu bahasa pemrograman.

Tabel 1. Notasi Diagram Alir

Untuk mengilustrasikan kegunaan dari diagram alir dapat dilihat pada gambar dibawah ini.

Gambar bagian (a) digunakan untuk menggambarkan struktur kontrol program, sedangkan gambar bagian (b) setiap lingkaran disebut dengan flow graph node, merepresentasikan satu atau lebih perintah prosedural. Urutan dari kotak simbol proses dan belah ketupat simbol keputusan dapat digambarkan menjadi sebuah node, sedangkan anak panah disebut edges, menggambarkan aliran dari kontrol sesuai dengan diagram alir.

Sebuah edge harus berakhir pada sebuah node walaupun tidak semua node merepresentasikan perintah prosedural. Area yang dibatasi oleh edge dan node disebut region, area diluar graph juga dihitung sebagai region.

Setiap representasi rancangan prosedural dapat diterjemahkan kedalam flow graph. Gambar (a) dibawah ini merupakan bagian dari PDL (Program Design Language) dan flow graph-nya (perhatikan nomor untuk setiap perintahnya).

Ketika kondisi gabungan ditemukan, maka penggambaran flow graph akan menjadi lebih rumit. Kondisi gabungan biasanya muncul jika satu atau lebih operator Boolean (OR, AND, NAND, NOR) ditemukan dalam perintah, seperti terlihat pada gambar (b) dibawah ini :

Contoh yang kedua mengenai penggambaran flow chart dan flow graf:

Gambar 5. Contoh yang kedua metode basis path

B) Kompleksitas Siklomatis (Cyclomatic Complexity)

Kompleksitas Siklomatis adalah metriks perangkat lunak yang memberikan pengukuran kuantitatif terhadap kompleksitas logis suatu program. Ketika digunakan dalam konteks metode ujicoba berbasis alur, nilai yang didapat akan menentukan jumlah jalur independen dalam himpunan path, serta akan memberi nilai batas atas bagi jumlah pengujian yang harus dilakukan, untuk memastikan bahwa semua pernyataan telah dieksekusi sedikitnya satu kali.

Jalur independent adalah jalur yang terdapat dalam program yang mengintroduksi sedikitnya satu rangkaian pernyataan proses atau kondisi baru.

Berdasarkan contoh PDL yang pertama, maka jalur independent yang didapat:

Jalur 1 : 1 – 11

Jalur 2 : 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11

Jalur 3 : 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11

Jalur 4 : 1 – 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11

Misalkan setip path yang baru memunculkan edge yang baru, dengan path :

1 – 2 – 3 – 4 – 5 – 10 – 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11

Path diatas tidak dianggap sebagai independent path karena kombinasi path diatas telah didefinisikan sebelumnya Ketika ditetapkan dalam graf alur, maka independent path harus bergerak sedikitnya 1 edge yang belum pernah dilewati sebelumnya.

Kompleksitas cyclomatic dapat dicari dengan salah satu dari 3 cara berikut :

1. Jumlah region dari grafik alur mengacu kepada komplesitas cyclomatic

2. Kompleksitas cyclomatic V(G) untuk grafik alur G didefinisikan sebagai:

V(G) = E – N + 2, dimana E = jumlah edge, dan N = jumlah node

3. Kompleksitas cyclomatic V(G) untuk grafik alur G didefinisikan sebagai:

V(G) = P + 1, dimana P = jumlah predicates nodes yang diisikan dalam grafik alor G

Simpul Predikat adalah penggambaran suatu node yang memiliki satu atau lebih inputan, dan lebih dari satu output.

Berdasarkan flow graph gambar (b) diatas, maka kompleksitas cyclomatic-nya dapat di hitung sebagai berikut :

1. Grafik alir diatas mempunyai 4 region
2. V(G) = 11 edges – 9 nodes + 2 = 4
3. V(G) = 3 predicates nodes + = 4

Hasil kompleksitas cyclomatic menggambarkan banyaknya path dan batas atas sejumlah ujicoba yang harus dirancang dan dieksekusi untuk seluruh perintah dalam program.

Berdasarkan contoh PDL yang kedua, maka jalur independent yang didapat :

Jalur 1 : 1,2,3 – 4 – 5 – 10 – 11 – 12

Jalur 2 : 1,2,3 – 4 – 6 – 7 – 9 – 10 – 11 – 12

Jalur 3 : 1,2,3 – 4 – 8 – 9 – 10 – 11 – 12

Contoh pengujian white-box

Menurut kebutuhan segitiga diberikan di bawah ini untuk menyelesaikan proses dan menyelesaikan tes:

1) masukan kondisi:

1, kondisi 1: a + b c

2, kondisi 2: a + c b

3, kondisi 3: b + c a

4, kondisi 04:00

5, kondisi 5-0

6, 7 kondisi 6-0, kondisi 7: a == b

8, kondisi 8: a == c

9, kondisi 9: b == c

10, kondisi 10: a2 + b2 c2 ==

11, kondisi 11: a2 + b2 c2 ==

12, kondisi 12: c2 + a2 == b2

2) output:

1, tidak dapat terbentuk segitiga

2, sebuah segitiga sama sisi

3, segitiga sama kaki

4, segi tiga siku-siku

5, segitiga umum

6, beberapa pihak tidak memenuhi pembatasan

Kesetaraan Partisi (EP) / Analisis Nilai Batas (BVA)

Partisi kesetaraan (EP) dan analisis nilai batas (BVA) memberikan strategi untuk menulis kasus pengujian white-box. Tidak diragukan lagi, setiap kali Anda menghadapi segala jenis nomor atau membatasi dalam persyaratan, Anda harus waspada untuk masalah EP / BVA.

Sebagai contoh, seseorang mungkin ingin membeli rumah, tetapi mungkin atau mungkin tidak memiliki cukup uang. Mengingat EP / BVA, saya ingin memastikan kasus uji kami meliputi:

1. properti biaya $ 100, telah memiliki $ 200 (kelas kesetaraan “memiliki cukup uang”)

2. properti biaya $ 100, memiliki $ 50 (kelas kesetaraan, “tidak punya cukup uang”)

3. properti biaya $ 100, $ 100 maka (nilai batas)

4. properti biaya $ 100, memiliki $ 99 (nilai batas)

5. properti biaya $ 100, memiliki $ 101 (nilai batas)

Dengan loop pemrograman (seperti perulangan while), pertimbangkan EP dan melaksanakan loop di tengah operasional terikat mereka. Untuk BVA, Anda akan ingin memastikan bahwa Anda menjalankan loop tepat di bawah, sudah tepat, dan tepat di atas kondisi batas mereka.

BLACK BOX TESTING

Black-box testing adalah metode pengujian perangkat lunak yang tes fungsionalitas dari aplikasi yang bertentangan dengan struktur internal atau kerja (lihat pengujian white-box). pengetahuan khusus dari kode aplikasi / struktur internal dan pengetahuan pemrograman pada umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni, aplikasi apa yang seharusnya dilakukan. Menggunakan deskripsi eksternal perangkat lunak, termasuk spesifikasi, persyaratan, dan desain untuk menurunkan uji kasus. Tes ini dapat menjadi fungsional atau non-fungsional, meskipun biasanya fungsional. Perancang uji memilih input yang valid dan tidak valid dan menentukan output yang benar. Tidak ada pengetahuan tentang struktur internal benda uji itu.
Metode uji dapat diterapkan pada semua tingkat pengujian perangkat lunak: unit, integrasi, fungsional, sistem dan penerimaan.Ini biasanya terdiri dari kebanyakan jika tidak semua pengujian pada tingkat yang lebih tinggi, tetapi juga bisa mendominasi unit testing juga.

Metode ujicoba blackbox memfokuskan pada keperluan fungsional dari software. Karna itu ujicoba blackbox memungkinkan pengembang software untuk membuat himpunan kondisi input yang akan melatih seluruh syarat-syarat fungsional suatu program. Ujicoba blackbox bukan merupakan alternatif dari ujicoba whitebox, tetapi merupakan pendekatan yang melengkapi untuk menemukan kesalahan lainnya, selain menggunakan metode whitebox.
Ujicoba blackbox berusaha untuk menemukan kesalahan dalam beberapa kategori, diantaranya :
1. Fungsi-fungsi yang salah atau hilang
2. Kesalahan interface
3. Kesalahan dalam struktur data atau akses database eksternal
4. Kesalahan performa
5. kesalahan inisialisasi dan terminasi

SUMBER : 

http://universitaspendidikan.com/pengertian-white-box-dan-contoh-white-box-testing/
http://bangwildan.web.id/berita-176-white-box-testing--black-box-testing.html